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

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

Late, and just for the record (see below):

On 28/12/2020 01:45, Manu Sporny wrote:
> On 12/24/20 3:26 AM, Martin J. Dürst wrote:
>> If I understand correctly, you would un-gzip it first, and only then
>> unzip it.
> 
> Yes... but remember you could have an application that's only really
> interested in un-gzip'ing and stopping there. That's a perfectly
> reasonable thing to do based on what ONE of the media subtypes is
> telling you. If all you can do as an application is ungzip... well,
> that's all you can do and the subtype makes that clear.
> 
>> In a slightly more realistic example, let's use svg+xml+gzip. Gzip is
>> more generic (because it can be applied to any kind of data) than
>> xml, and you definitely first have to un-gzip before feeding the
>> document into an XML parser.
>>
>> But you may be right that there are cases where the terminology
>> 'generic'/'specific' may not be adequate. foo+gzip+zip (foo gzipped
>> and then zipped) may make as much (or as little!) sense as
>> foo+zip+gzip,
> 
> Yes, agreed that "specific" is not adequate, because there are multiple
> "specific" identifiers that are valid, especially for the following use
> case:
> 
> application/did+ld+json
> 
> These are all valid subtypes: "json", "ld+json", "did+ld+json" resulting
> in these valid media type interpretations:
> 
> application/json
> application/ld+json
> application/did+ld+json
> 
> That's what we're trying to say... does that hold together?
> 
>> The problem with this approach may be that currently existing
>> implementations, as well as some future implementations, may just
>> look at the rightmost + and the following alphabetic characters.
>> Therefore, you need to make sure that people constructing/proposing
>> suffix combinations will choose the right order, and that means that
>> you have to have some language about suffix ordering anyway.
> 
> Ok, got it. Would adding language that explains the above (and the
> previous response to Murray) make sense?

Yes, I think such language is needed. Otherwise, some people may 
interpret it the other way round.

> We expect that many applications don't do this sort of thing today,
> rather either matching on the complete mime-type and doing processing,
> or not. We are just trying to be complete about the mental model of
> media subtypes and thought we were documenting something that was
> already more or less there... but perhaps not? In any case, does adding
> language about suffix ordering and how to interpret it address your
> concern, Martin?

Yes. It's not exactly my concern, as my and your mental models seem to 
be rather close, but others may not have the same model, so we need to 
be clear what the model is.

Regards,   Martin.