Closed
Description
For the "image layout" that can be tar'd, zip'd, etc we need to create the spec and media-type for the "descriptor"
https://github.com/opencontainers/image-spec/blob/master/schema/defs-image.json#L23
Relevant IRC convo:
4:08 PM <philips> stevvooe: this response? https://github.com/opencontainers/image-spec/pull/82#issuecomment-221980346
4:09 PM <stevvooe> philips: yes
4:09 PM <stevvooe> philips: it just means that we deserialize a descriptor, rather than a few fields of the manifest
4:09 PM <philips> stevvooe: I don't know what you mean by half-deserialized still
4:09 PM <philips> stevvooe: what is a descriptor?
4:09 PM <stevvooe> philips: "partially-serialized" would probably be more accurate
4:10 PM <stevvooe> stevvooe: this structure: {"size": 4096, "digest": "sha256:afff3928", "mediatype": "application/vnd.oci.image.manifest.v1+json"}
4:10 PM <philips> stevvooe: ah, ok. well, did you see my concern about mime types?
4:10 PM <stevvooe> philips: yea, and now i think i understand your example
4:11 PM <philips> stevvooe: like my structure is identical but allows for N media types: https://github.com/opencontainers/image-spec/pull/82#issuecomment-221760143
4:11 PM <stevvooe> philips: i think if we push that dispatch to a manifest list, we can avoid a large amount of unverified content
4:12 PM <philips> stevvooe: so you suggest always force a manifest list?
4:12 PM <philips> stevvooe: like the manifest list is always the thingie we point to in this "container"
4:12 PM <stevvooe> philips: so, the options are <descriptor> -> <manifest list> or <new format: [descriptor]> -> <arbitrary>
4:13 PM <stevvooe> philips: that might be the right approach
4:13 PM <philips> stevvooe: yea, not opposed to the descriptor thing for "file transport containers"
4:13 PM <philips> stevvooe: and always pointing to a manifest list makes sense, I think.
4:13 PM <stevvooe> philips: btw, here is the descriptor def : https://github.com/opencontainers/image-spec/blob/master/schema/defs-image.json#L14
4:15 PM <philips> stevvooe: got it, we only ever refer to it that way in code instead of in the spec so I wasn't familiar with the term
4:15 PM <philips> stevvooe: thanks, makes sense
4:17 PM <stevvooe> philips: great! we may want to pull out the descriptors into another specification, maybe post-.10
4:17 PM <wking> philips: re: "always pointing to a manifest list makes sense". If you don't assume that, it's easy to check and have tooling error out if it hits an unsupported MIME type
4:18 PM <wking> If you do assume that, you're stuck with it for as long as you want to keep backwards compatability with old tooling
4:18 PM <philips> stevvooe: like into their own mime-type?
4:18 PM <wking> (assuming the old tooling also assumed that and didn't check the descriptor MIME type https://github.com/opencontainers/image-spec/blob/master/schema/defs-image.json#L23
4:19 PM <stevvooe> philips: yes. file an issue and i'll take that on
4:20 PM <philips> wking: ack, right, I think the list is sufficiently dumb/flat enough to not require breaking changes for a long time.
4:20 PM <philips> stevvooe: sounds good, thanks.
4:20 PM <wking> sure, but what's the benefit to taking that risk in the spec?
4:20 PM <philips> wking: what are you suggesting as an alternative?
4:21 PM <wking> that the spec not require a particular MIME type for the reference descriptors
4:21 PM <philips> wking: so a descriptor sans mediatype? {"size": 4096, "digest": "sha256:afff3928"}
4:21 PM <wking> I am +1 on clients only supporting the manifest list for as long as they make sense, but if the spec *requires* a given MIME type it makes the eventual upgrade awkward
4:22 PM <wking> philips: no, include the linked MIME type in the descriptor, just don't say "reference descriptors MUST set ...manifest.list... as their mediaType"
4:22 PM <philips> oh, right, yes, +1
4:22 PM <philips> that was my intention/plan