MIME Types for DID Documents and Representations

[jricher]

What mime types should we use for DID documents? This is especially important in the light of #253 that allows for content-type and accept negotiation and signaling.

Note: this has been updated to reflect comments below

I propose that we create a core DID document mime type and tag the representation onto it, like:

• application/json+did
• application/jsonld+did
• application/cbor+did
• application/pdf+did

Pro: this would allow us to define things like fragment behavior based on application/did.

Con: native parsers would have to be told that application/json+did is actually application/json.

Some examples have the relationship inverted as:

• application/did+json
• application/did+json+ld

Pro: this lets parsers handle things more easily, potentially.

Con: we have to re-define DID document behavior across lots of different representations.

[iherman]

• application/did+json
• application/did+jsonld
• application/did+cbor
• application/did+pdf

The first, third, and fourth look fine to me. However, the second is a problem: at this moment application/jsonld does not exist: the media type for JSON-LD is application/ld+json.

The ideal would be application/did+ld+json, but that seems to hit some IANA problems. The issue is pending, see, for details and some history, #208.

Con: native parsers would have to be told that application/did+json is actually application/json.

I do not understand this remark. The fact that application/did+json is, in fact, application/json plus some additional feature is exactly what IANA defines and, afaik, browsers and other agents, by and large, function accordingly. Ie, I do not see that as a 'Con'.

[peacekeeper]

Per #241, which will likely be merged soon, MIME types will be defined by compliant repesentations. My DID Resolution PR #247 referenced those new sections when talking about accept and content-type. I don't think anything else has to be done with regard to MIME types.

I agree with @iherman that the topic of MIME types has been discussed in the past, we even had a call with the JSON-LD WG to discuss different options. In any case, we have to be compliant with IANA rules about how suffixes work.

Current examples have the relationship inverted as:

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

This is definitely wrong (+did is not a registered suffix), where did you find that?

[jricher]

@iherman application/json+did can be effectively treated as application/json by a parser with no ill effects, at least that's my understanding of how the + character semantics are defined. This model is also why you can't have multiple levels of +, as I understand it.

That's why I'm proposing application/did as the root with multiple encodings in the + portion.

[dmitrizagidulin]

@jricher - that's reversed. It's application/<subtype>+<type>

[iherman]

@iherman application/json+did can be effectively treated as application/json by a parser with no ill effects, at least that's my understanding of how the + character semantics are defined. This model is also why you can't have multiple levels of +, as I understand it.

As @dmitrizagidulin and @peacekeeper already remarked application/json+did is not a valid media type as of today, only application/did+json could be (if registered); the parser considering it as json would be already true. I do not see an issue here.

[jricher]

@dmitrizagidulin @iherman Thanks, I'll change the text of the issue to reflect that.

[msporny]

RFC6838 defines how structured suffixes should be used. application/json+did and variants are not valid options. The specific section regarding structured suffixes is here:

https://tools.ietf.org/html/rfc6838#section-4.2.8

More elaboration here:

https://tools.ietf.org/html/rfc6839

AFAIK, the current options are:

• application/did+json
• application/did+ld+json (if it's approved by IANA, which is under study right now)
• application/did+cbor (if we get a CBOR representation done)

There is already a section in the spec that establishes MIME Types:

https://w3c.github.io/did-core/#iana-considerations

That was merged two months ago:

#196

@jricher, this seems to be a duplicate of an issue that has been resolved. Can we close this issue?