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

From: Eric Prud'hommeaux <[email-masked]>
Date: Fri, 5 Feb 2021 10:16:04 +0100

On Sun, Dec 27, 2020 at 11:45:33AM -0500, 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

I don't think this is a good example of "specific" being
inadquate. It's pretty obviously a DID, which can be processed as
JSON-LD, which can even fall back to JSON. A better example might be a
doc that unions a couple of RDF graphs, e.g. vc and did. Here, we'd
make an arbitrary choice between application/vc+did+ld+json and
application/did+vc+ld+json, neither of which are trivially
recongizable as matching application/did+ld+json.

The problem is that there's no way to express that "did+vc" satisfies
any of them separately. AFAICT, every case where "specific" is not
adequate comes down to that ANY use case. We'd like a semantics like:
  All(application, All(json, All(ld, Any(did, vc))))

One cogent approach would be to say that media types capture generic
formats and their profiles capture vocabularies/use cases. For example
`application/svg+XML` would be `application/XML; profile=svg` and my
did+vc example would be `application/ld+json; profile=did,vc`. If you
need to capture nuances beyond the embedded vocabulary, you would
invent a profile (currently addressed by inventing a media type).

The problem is the migration path. We get a lot done with media types
and it would be nice to not have to freak out and update every piece
of code simultaneously. However we introduced an Any semantics,
there'd be an uncomfortable moment where freshly-written, Any-aware
applications were running on Any-unaware libraries, APIs and browsers,
which is typically ground for rebellion.

A not-too-painful way to get there would be to require e.g. profiles
on vocabulary-specific media types to give HTTP, libraries, servers,
browsers and file managers time to migrate to using the profile. The
web platform moves pretty quickly and it's not like we'd be breaking
old apps with the migration. Eventually, we might get to a point where
new lanuages and protocols like DID wouldn't need to register a new
media type.

PROPOSAL:

1. Register vocabulary-specific media types with a required profile.

2. (Conservatively) register types for combinations of vocabs ordered
   alphabetically ("did+vc+...", not "vc+did+..."), including profiles
   that decomposes to identify both vocabs.

3. Invent profiles for existing X+xml media types.

4. Update 7303 (+xml) and 6839 (+json) to encourage the use of
   accompanying profiles.

5. Years hence, evaluate whether we can quit registering
   vocab-specific media types.

I can see this migrating starting in specific communities, e.g.
Semantic Web and creeping out from there to the Web Platform.

If we're not willing to try something so disruptive, we may as well
publish application/did+ld+json without a profile and let them get on
with their work.

> 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?
> 
> 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
> 
> -- 
> 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
> 
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types