Re: [media-types] Media subtypes containing "+"

[Manu Sporny <[e-mail]>]

Hi Murray, Graham, and Martin,

I'm the lead editor of the Decentralized Identifier Core specification
in the W3C DID WG and have been working with Amy on the
media-types-with-multiple-suffixes document. The W3C DID WG specifically
needs it to be "done enough" for the JSON-LD serialization of DID
Documents. We plan to enter the Candidate Recommendation phase toward
the end of January and getting this document sorted is becoming a
priority. So any thoughts on whether we should stick with the direction
we're going in or have some sort of "backup plan" would be welcome.
Responses to statements below...

On 12/23/20 5:35 PM, Murray S. Kucherawy wrote:
> (1) In terms of handling, you might also propose this to [e-mail]
> <mailto:[e-mail]> (the general ART area mailing list) and to
> [e-mail] <mailto:[e-mail]> (the DISPATCH working
> group); the latter would be the place to get a discussion going about
> an appropriate venue for handling the document.

Hmm, by "handling" do you mean "further discussion"? We were under the
impression that the media-types group was the right forum for the
discussion. We're a bit lost as to how we'd publish this -- is that what
you're getting at?

> (2) I'm unclear on the nomenclature, in particular that the most 
> specific suffix is the first in the list of suffixes (when read left 
> to right) and the most generic is last.  My thought is that the list 
> needs to be ordered, and we just need to specify what that ordering 
> is.  For instance, I'm dreaming up a (possibly absurd) example of 
> "foo+zip+gzip".  Would I un-gzip it first, or unzip it first, with 
> the goal of getting a "foo" out of it?  Why would I consider one of 
> them more specific or generic than the other?

Our understanding was that the media-type string could contain multiple
subtypes and that there may be generic processing applications that
could determine if they could perform processing based on each generic
subtype.

For example, let's take the media type we're most concerned about right now:

application/did+ld+json

There are classes of processors that would be interested in each
subtype, for example:

json -- JSON linting software, JSON storage software that could store
        the document directly in an unstructured database, etc.

ld+json -- JSON-LD linting software, JSON-LD document processing
           software (expansion/compaction), JSON-LD to other RDF syntax
           processing software, etc.

did+ld+json -- Decentralized Identifier Document serialized as JSON-LD
               processing software such as DID resolution software,
               DID dereferencing software, Linked Data Signature
               processing software, etc.

So, the subtype(s) you're interested in depends on where you're
operating in the stack... there is definitely an answer to the "more
specific" / "more generic" question and the spec extension attempts to
point that out. I'm guessing that what you're saying is that "it needs
to do a better job at making that distinction"?

> If (based on the end of Section 1.1) what you're suggesting is 
> actually to in effect consider "+zip+gzip" a single unified suffix
> of its own, then I think what we're really saying here is that
> there's only ever one suffix, but that suffix can contain a "+".
> That is, when parsing the media subtype, the suffix is everything at
> and after the first "+" irrespective of how many "+" characters there
> are.  If that's the case, it might be simpler to just say it that way
> so that the reader doesn't need to think about a gradation of
> most-to-least specific.

Hmm, I don't think that's what we're trying to say. I think what we're
trying to say is the above, or to put it another way:

When there are multiple plus signs, there are multiple subtypes.
Subtypes that are registered have clear processing rules by pointing to
the specification that defines those processing rules.  So,
"application/did+ld+json" may be processed as "application/json",
"application/ld+json", and "application/did+ld+json"... and it's up to
the application to decide which subtype it would like to apply (all of
them are valid).

Does that make sense? Does anyone know of any media types where that
rationale breaks down? Or is that a nonsensical way to think about the
problem?

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches