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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Jan 2021 09:57:57 -0800

Just on the "handling" question:

On Sun, Dec 27, 2020 at 8:36 AM Manu Sporny <[email-masked]>
wrote:

> On 12/23/20 5:35 PM, Murray S. Kucherawy wrote:
> > (1) In terms of handling, you might also propose this to [email-masked]
> > <mailto:[email-masked]> (the general ART area mailing list) and to
> > [email-masked] <mailto:[email-masked]> (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?
>

By "handling", I meant the choice of path to publication as an RFC this
work should follow.

The current preference for unchartered work that falls into the ART area is
to discuss it on the lists mentioned above.  Since this work is specific to
media types, discussing it on this list first was also appropriate.
DISPATCH will reach consensus on whether the document should be a one-off
Area Director sponsored document, routed to a working group that exists and
has a charter that can accept the work, or handled by a new working group
(which they would then help you charter).

-MSK

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 12 Jan 2021 16:58:22 +0900

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.