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

["Martin J. Dürst" <[e-mail]>]

On 23/07/2020 04:55, Murray S. Kucherawy wrote:
> Hi Manu, thanks for chiming in.
> 
> On Wed, Jul 8, 2020 at 10:15 AM Manu Sporny <[e-mail]>
> wrote:
> 
>> So, we're getting cornered into having to pick something and it's going
>> to come down to:
>>
>> application/did+jsonld
>> application/did+cborld
>>
>> OR
>>
>> application/did-ld+json
>> application/did-ld+cbor
>>
>> OR (this seems to be the most tenable one)
>>
>> application/did+ld+json
>> application/did+ld+cborld
>>
>> The W3C JSON-LD 1.1 WG is at the end of it's life, and has not been able
>> to push this decision forward at IETF, so we can't easily register a new
>> MIME Type at this point. I'm sure there are some standards shenanigans
>> that could be played to do that between W3C Staff and IETF ADs, but
>> registering a new MIME Type for "jsonld" is broadly held as the wrong
>> thing to do. If we go down that path, IETF might consider rejecting all
>> new subtype submissions and JSON-LD will become a cautionary tale of
>> where subtypes went wrong... or perhaps there can be guidance given on
>> when *not* to use a subtype that would have prevented the JSON-LD folks
>> (specifically, me as the Editor at the time) from suggesting
>> "application/ld+json" in the first place.
>>
>> The alternate path is that "application/did+ld+json" is allowed, with a
>> clear rationale on why that's a good thing. We have already tested a
>> variety of popular MIME Type parsers across multiple languages out there
>> in the wild and they seem to do the right thing.
>>
> 
>> We go into CR in the W3C DID WG in the next couple of months and we'd
>> like to register all of the relevant MIME Types for the Decentralized
>> Identifier specification by that time. We'd like to register at least
>> this one:
>>
>> application/did+ld+json
>>
> 
> Mark is asking the right question, I feel: Do we know how well suffixes
> have fared, in terms of having been a benefit?  I'm not sure how one would
> go about determining this.  I would love to hear suggestions.

I'm also not sure how we would do this. But one thing that occurs to me 
is that it may differ quite a bit depending on the actual suffixes. In 
particular, the benefits for +ld+json should be rather high, because 
JSON LD can be interpreted as RDF, and RDF data from different sources 
and with different vocabularies can be integrated rather easily (at 
least so the story goes). So I'm not surprised to see such a proposal 
come from such a WG.

Another point is that these suffixes are not only for machines. They may 
help humans, too. They may help people understand how a document is 
structured. And they may also help direct people who design new types to 
use existing types and build upon them, rather than invent their own 
clundges.

> What would break on the Internet if we were to do that?

It's easily possible that there is some software that is looking for the 
first or the last '+' in a subtype, with the expectation that it's the 
only one, or that checks that there is at most one '+'.


> Are there other
>> options that we're not seeing?
>>
> 
> I also don't know how to answer this, other than to claim that we tend to
> err on the side of being cautious about making assumptions.  Having never
> implemented a browser or something else that has to handle media types, I
> don't know if I would look for a suffix by searching for a "+" from the
> left or from the right, and thus I don't know what would break because the
> results here are obviously quite different.

The 'correct' (according to a comment in the ABNF in RFC 6838, see 
https://tools.ietf.org/html/rfc6838#section-4.2) is that one should look 
for the last '+'.

 >>>>
      restricted-name-chars =/ "+" ; Characters after last plus always
                                   ; specify a structured syntax suffix
 >>>>

> My inclination is to ask that we debate a draft that's an update to RFC
> 6838, which describes media type suffixes more precisely in a way that
> explains how to use what looks like a nested suffix structure like this.

This seems to make sense.

> That is, make it clear that "application/did+ld+json" is to be interpreted
> as a type of "application" and a subtype of "did" with a suffix of
> "+ld+json", or a subtype of "did+ld" with a suffix of "+json", or a subtype
> of "did" with two ordered suffixes.

I'd propose it be interpreted as two suffixes, along the following 
hierarchy:
application
application/json
application/ld+json
application/did+ld+json

The change of direction is unfortunate, but we already have it here and 
e.g. in URIs. And we have to be careful with the term 'subtype'. In RFC 
6838, that refers to everything after the slash, i.e. 'did+ld+json'.

Regards,   Martin.

> Is someone from the W3C willing to put such a draft together?
> 
> -MSK