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

[Manu Sporny <[e-mail]>]

Murray S. Kucherawy wrote:
> We had the applicant remove this text and instead suggest that they need to
> register "+ld+json" independently as a media type suffix, but that such a
> registration would likely be denied until such time as the community has
> had a chance to discuss its implications.

Hi Murray, Mark, and Julian,

Let me try to shed some light on how this choice is affecting the W3C
WGs working on the JSON-LD, Verifiable Credentials, and Decentralized
Identifiers specifications.

Way back in the day, when we were working on JSON-LD 1.0, we had to
register a media type and the suggestion given by the powers that be at
the time was to put the syntax we were using last. We were encoding
Linked Data in JSON format, so the natural choice became
"application/ld+json" as the media type and subtype.

Fast forward four years and we were working on Verifiable Credentials,
which have an abstract data model that could be expressed in various
formats (JSON-LD or CBOR-LD), but JSON-LD was the primary way, and we
didn't have a dire need to go do something like
"application/vc+ld+json", and we were concerned that attempting that
would just be rejected:

https://github.com/w3c/vc-data-model/issues/421

At that point, there was a suggestion that we do "jsonld" as the media
type, which would have had negative consequences on all of the software
that is deployed in production today and goes against the tribal
suggestion that "ld+json" is the right thing to do anyway. Doing
"jsonld" was just a hack to get around the question being asked in this
thread -- which is, how deep do the subtypes go?

https://github.com/w3c/json-ld-syntax/issues/287

We ended up not registering a MIME Type for Verifiable Credentials and
instead it was suggested, by the JSON-LD WG, that we register a "Profile
Type" for JSON-LD in this registry:

https://www.iana.org/assignments/profile-uris/profile-uris.xhtml

No one has done that to date, because you can't easily transmit a
Profile Type in a variety of the use cases we were looking at (such as
MIME Type associated with a file on disk based on file extension -- most
operating systems don't support more than just a string expressing MIME
Type).

Fast forward another four years and we're now engaged in the same
discussion in the W3C Decentralized Identifier Working Group (This isn't
going away, it's only going to get worse -- we have a handful of other
specs in the works with the same problem). In the DID WG specifically,
we're not going to be able to dodge the question like we did in the VCWG
and JSON-LD 1.1 WG because there are at least four MIME Types being
contemplated where JSON-LD Profiles won't work:

application/did+json
application/did+cbor
application/did+ld+json
application/did+ld+cbor

... and there is a growing need for a MIME Type for Verifiable
Credentials (as they're starting to be serialized to disk and there are
use cases that put these things in directories on desktops and laptop OSes):

application/vc+ld+json
application/vc+ld+cbor

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

What would break on the Internet if we were to do that? Are there other
options that we're not seeing?

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