Brandon Mitchell

> Fixed this in [#3524](https://github.com/project-zot/zot/pull/3524) Thanks. I've tested and the fix works for me.

> What we're finding dubious is upholding the same guarantees for manifest lists. In a normal multiplatform image download flow, the client asks for `/v2//manifests/`, which returns a manifest list...

> > As for adding a url field to the [descriptor](https://github.com/opencontainers/image-spec/blob/main/descriptor.md) type, as you've proposed, you can aaaaalmost do this today with the existing urls field, except that: > >...

To oversimplify this, I think you're looking at the index as an abstraction that's part of the tag, while the rest of OCI treats the index as part of the...

> I'm also unsure what these issues around security, functionality, and usability are. Vendors may sign the index digest and depend on the content not changing for security. Functionality and...

Following up because I see one project implementing this by leveraging authentication, an extra field added to the username to trigger the registry to change which image is returned: https://app.metahub-registry.org/

For ECR, try removing the platform from the subject. For GitLab, they have an allow list on the media type, not sure if the empty config media type is on...

> But it should work with the platform field as the subject specifies a descriptor right? It's a descriptor, and in an index the manifests there typically include a platform....

The problem text has been changed from: > An encountered mediaType that is unknown to the implementation and cannot be processed MUST be ignored. to: > Implementations storing or copying...

Closing since I believe the concern was resolved, but feel free to update the PR and reopen if there are still gaps.