add application/vnd.oci.image.layer.v1.tar+zstd to official media type?

[AkihiroSuda]

containers/image#639 (comment)

@vbatts @giuseppe

[vrothberg]

👍 from my side

FYI @mtrmac @mrunalp @rhatdan

[rhatdan]

👍

[cyphar]

Sounds like a good idea to me, the main question is whether we should require support or define it as a SHOULD (such that we define +zstd to mean something specific without requiring everyone implement support).

Though, given there is a C library (used fairly widely now) and implementations for Go and Rust, I'd be willing to argue that implementing support shouldn't be an onerous requirement for image consumers.

Does anyone want to volunteer to do the PR, or should I?

[vbatts]

I would welcome a PR on this. The language for this kind of extensibility ought to allow for future permutations as well, even if it calls out explicitly `+zstd` for now.

…

On Mon, Aug 5, 2019 at 6:19 AM Aleksa Sarai [see §317C(6)] < ***@***.***> wrote: Sounds like a good idea to me, the main question is whether we should require support or define it as a SHOULD (such that we define +zstd to mean something specific without requiring everyone implement support). Though, given there is a C library (used fairly widely now) and implementations for Go and Rust, I'd be willing to argue that implementing support shouldn't be an onerous requirement for image consumers. Does anyone want to volunteer to do the PR, or should I? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#787?email_source=notifications&email_token=AAAQL2OEN2LDOYTZ5RBPJKTQC75DPA5CNFSM4II6WKK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RMC7Y#issuecomment-518177151>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQL2LCAYGY4YYMYX7KPY3QC75DPANCNFSM4II6WKKQ> .

[giuseppe]

I've opened a PR here: #788

[jonjohnsonjr]

@vbatts do we care if OCI media types are valid RFC6838 media types? E.g. "zstd" isn't defined in the Structured Syntax Suffix Registry.

Media types that make use of a named structured syntax SHOULD use the appropriate registered "+suffix" for that structured syntax when they are registered. By the same token, media types MUST NOT be given names incorporating suffixes for structured syntaxes they do not actually employ. "+suffix" constructs for as-yet unregistered structured syntaxes SHOULD NOT be used, given the possibility of conflicts with future suffix definitions.

This ties into #747 as well. I'm not sure if the +enc double-suffix is valid (though I mostly skimmed that RFC and might misunderstand the grammar described).

I was thinking about how I'd go about adding support for zstd in various places, and I'm a bit worried that, as we add more dimensions to the media types, we're going to end up with a combinatoric explosion of valid media type strings. As a registry/client author, it's currently easy enough to hard-code these strings and special-case e.g. nondistributable layers or the compression algorithm; however, I can imagine that comparing hard-coded strings will become sub-optimal at some point in the future, and we'd be better off parsing these strings into a structured form.

1. Any thoughts on whether we should try to follow that RFC? FWIW, there's a procedure for registering a suffix, if anyone wants to take a stab at adding +zstd.
2. Is there blessed code anywhere for parsing OCI media types? Or is everyone just directly comparing these strings?