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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Dec 2020 14:35:38 -0800

Hi Amy, sorry for the delay.  Thanks for taking this on.

A question and a suggestion:

(1) In terms of handling, you might also propose this to [email-masked] (the
general ART area mailing list) and to [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.

(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?

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.

-MSK

On Mon, Nov 30, 2020 at 6:49 AM rhiaro <[email-masked]> wrote:

> Hi all,
>
> As requested, we have a draft which is an update to RFC 6838, so that we
> can discuss something concrete around multiple subtype suffixes:
>
>
> https://datatracker.ietf.org/doc/draft-w3cdidwg-media-types-with-multiple-suffixes/
>
> Does anybody have a few moments to review this, so we can work on moving
> this forward?
>
> Many thanks,
>
> Amy
>
> On 24.10.2020. 16:35, rhiaro wrote:
> > Hi all,
> >
> >> Is someone from the W3C willing to put such a draft together?
> > I'm a member of the W3C DID WG and have at long last drafted the update
> > to RFC6838 that has been discussed in this thread:
> >
> >
> https://datatracker.ietf.org/doc/draft-w3cdidwg-media-types-with-multiple-suffixes/
> >
> > I hope I have captured the intent of the comments so far in this thread
> > and used the correct language. Any and all feedback on refining this is
> > gratefully received.
> >
> > Amy
> >
> >
> > _______________________________________________
> > media-types mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/media-types
> >
>
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types
>

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Dec 2020 17:26:31 +0900

> Why would I consider one of them more specific or generic than the other?

If I understand correctly, you would un-gzip it first, and only then 
unzip it. 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,

> about a gradation of most-to-least specific.

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.

Regards,   Martin.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 24 Dec 2020 13:41:08 +0000

[Re-sending:  I originally sent this response some time ago, but I'm not seeing 
it on the mailing list - I did respond to the prompt to confirm submission from 
a non-subscribed email address.]

Hi!

I think this is a useful contribution, thanks!

I have three comments:

1. In the discussion of suffix registrations, the draft says "each subset of 
suffixes, starting from the right-most suffix, MUST be individually registered 
as a subtype in its own right" - I think this is incorrect use of the term 
"subtype" as used by the MIME specification.  RFC6838 uses the phrase "media 
type name suffix" and/or "Structured Syntax Suffix Registration Template".

   https://www.rfc-editor.org/rfc/rfc6838.html#section-6

It's not clear to me what the best term would be, but I'd probably aim for 
something like "media type name suffix" or "subtype suffix" if that's clear from 
context.

2. I think an example would help to show what is being proposed (I think the 
description is clear enough, but it's always good to have something concrete to 
cross-check against).  In particular with reference to registration of multiple 
subtype suffixes used together.

E.g. in the case of refinements of application/ld+json (per 
https://w3c.github.io/json-ld-syntax/#iana-considerations), one could imagine 
more specific types defined; e.g.

     application/invoice+ld+json

Per the description, I think this would require the following suffixes have been 
registered:

     +json
     +ld+json

But not:

     +ld

And if this data may be offered with alternative RDF syntaxes, such as, e.g.:

     application/invoice+ld+rdf+xml

then:

     +xml
     +rdf+xml
     +ld+rdf+xml

3. A nit:  the draft makes reference to and uses RFC2119 language.  It is usual 
in RFC documents I've seen to explicitly call this out in the document.  E.g.

   https://www.rfc-editor.org/rfc/rfc6838.html#section-1.2

#g

-- 
Graham Klyne
mailto:[email-masked]
Skype/Twitter: @gklyne

---

From: Manu Sporny <[email-masked]>
Date: Sun, 27 Dec 2020 11:36:36 -0500

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 [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?

> (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

---

From: Manu Sporny <[email-masked]>
Date: Sun, 27 Dec 2020 11:45:33 -0500

On 12/24/20 3:26 AM, Martin J. Dürst wrote:
> 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 
> '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?

> 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?

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?

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Sun, 27 Dec 2020 11:51:40 -0500

On 12/24/20 8:41 AM, Graham Klyne wrote:
> 1. In the discussion of suffix registrations, the draft says "each 
> subset of suffixes, starting from the right-most suffix, MUST be 
> individually registered as a subtype in its own right" - I think this
> is incorrect use of the term "subtype" as used by the MIME
> specification. RFC6838 uses the phrase "media type name suffix"
> and/or "Structured Syntax Suffix Registration Template".
> 
> It's not clear to me what the best term would be, but I'd probably
> aim for something like "media type name suffix" or "subtype suffix"
> if that's clear from context.

Ok, can do... we'll probably go with the more precise "media type name
suffix".

> 2. I think an example would help to show what is being proposed (I
> think the description is clear enough, but it's always good to have
> something concrete to cross-check against).

Yes, agreed, we'll add an example and use a real one as an example --
application/did+ld+json

> In particular with reference to registration of multiple subtype
> suffixes used together.
> 
> https://w3c.github.io/json-ld-syntax/#iana-considerations), one
> could imagine more specific types defined; e.g.
> 
> Per the description, I think this would require the following
> suffixes have been registered:
> 
> +json +ld+json
> 
> But not:
> 
> +ld

Yes, that is correct. We may want to put additional language in there
that states that you can only build valid media type names from a
structured suffix from right to left (not left to right).

> +xml +rdf+xml +ld+rdf+xml

Yes, agreed.

> 3. A nit:  the draft makes reference to and uses RFC2119 language.
> It is usual in RFC documents I've seen to explicitly call this out in
> the document.  E.g.
> 

Ok, will do, thanks Graham!

-- manu

---

From: rhiaro <[email-masked]>
Date: Mon, 28 Dec 2020 15:53:49 +0000

Hi all,

Thank you all for the feedback so far. I've made some edits based on the
suggestions to try to clarify things.

Still waiting for the upload confirmation email from the ietf tracker
for the new version, but meanwhile the draft is at:
https://rhiaro.github.io/draft-w3cdidwg-media-types-with-multiple-suffixes/

Amy