Did-core: Fragment identifier semantics are independent of URI scheme

[burnburn]

Taken over from the CCG (https://github.com/w3c-ccg/did-spec/issues/82).

Notifications to @msporny @peacekeeper

[dlongley]

It seems to me that what we need to resolve is this would be a PR with a MIME type registration section (per https://github.com/w3c-ccg/did-spec/issues/82#issuecomment-388822667).

[brentzundel]

I'd like to move this forward, and have no problem with the proposed solution, but am not sure what a MIME type registration section looks like. If someone can point me to an example, I will raise a PR.

[iherman]

@brentzundel is this what you are looking for?

https://w3c.github.io/json-ld-syntax/#iana-considerations

However... @msporny referred to (in https://github.com/w3c-ccg/did-spec/issues/82#issuecomment-390989279) to the possibility of something like application/did+ld+json. Alas!, that does not work. The current IANA rules allow a two level specification only, i.e., only one '+' signs in the media type.

Another possibility is to use profiles for json-ld. Profiles' usage is a mouthful, not very nice, but I am not sure we have another choice.

[brentzundel]

@iherman thank you for pointing me to that resource, that is exactly what I was looking for.
I can probably create a PR with similar language for the did spec, but would need guidance on what to recommend.
@msporny, @dlongley, @peacekeeper are we looking at something like application/did+json?

[msporny]

The current IANA rules allow a two level specification only, i.e., only one '+' signs in the media type.

Hmm, couldn't find that "only one '+' sign in the media type" text in the RFC... :)

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

application/did+ld+json seems to work in common tooling:

npm install mime
node (v10)
> const mime = require('mime');
> mime.define({'application/did+ld+json': ['did']})
undefined
> mime.getType('did');
'application/did+ld+json'
> mime.getExtension('application/did+ld+json')
'did'
> mime.getExtension('application/ld+json')
'jsonld'
> mime.getExtension('application/did+ld+json; charset=utf8')
'did'

Options seem to be:

• application/did+ld+json
• application/did+json
• application/ld+json (with a profile), but doesn't meet one of the (potential) requirements of serializing DID Documents out to disk and having a file extension associated with it.

@brentzundel -- I don't expect any of this would keep you from writing the section, just pick one... did+json is probably the safest, and we can refine it once the PR has been raised.

[iherman]

@msporny I looked through

https://www.iana.org/assignments/media-types/media-types.xhtml#application

and there was not a single example for a registered type for multiple '+' signs. You are right that, in a first reading, https://tools.ietf.org/html/rfc6838#section-4.2.5 does not seem to make a restriction there (although I am not sure what the term 'suffix' means precisely in that section, whether it can only refer to the top level type under application or not). To be on the safe side I have sent a mail to my more knowledgeable colleagues to ask for advise.

(I know that other groups hit this issue and shied away from using a deeper hierarchy.)

---

Of course, this issue becomes moot if application/did+json is chosen.

The choice between that one and application/did+ld+json amounts to the question whether we want to hide, resp. advertise, the JSON-LD nature of the did document. Note that JSON-LD 1.1 processors _do_ accept files using "plain" JSON as media type (see JSON-LD 1.1 document loader spec), so the issue is more a matter of what we want to announce rather than technical.

[peacekeeper]

The ABNF in RFC6838 says _"Characters after last plus always specify a structured syntax suffix"_.

I think this doesn't mean that application/did+ld+json would be wrong, only that +json (not +ld+json) would be considered the "suffix".

If we want to avoid the two pluses, then something like application/did-ld+json could also be an option, but that's probably more confusing than helpful?

I do think it's important to point out the JSON-LD nature one way or another.

[iherman]

If we want to avoid the two pluses, then something like application/did-ld+json could also be an option, but that's probably more confusing than helpful?

I am afraid that, indeed, this would be confusing...

I do think it's important to point out the JSON-LD nature one way or another.

Which pretty much leaves us with the option of application/ld+json with a profile, although I do share the issues @msporny raised on that.

[TallTed]

There are many examples of hyphenated construction in MIME types, including jwk-set+json, so I think did-ld+json would be OK, as would ld-did+json, and even did+ld+json (which is definitely not forbidden by RFC).

One of the points of the + is to have a fallback, from a more-specific (and typically, newer) format to a less-specific (and typically, older) format -- so ld+json lets software that understands JSON-LD treat that file as such, while software that only understands JSON can ignore the ld+ aspect and work only with the json (albeit with less functionality); similar to application/rdf+xml.

Alternatively, we might pursue registration of application/jsonld as an alias of application/ld+json, such that we could then register application/did+jsonld ... or push for an update of the RFC, to explicitly cover the effect multiple + separators.

[iherman]

There are many examples of hyphenated construction in MIME types, including jwk-set+json, so I think did-ld+json would be OK, as would ld-did+json, and even did+ld+json (which is definitely not forbidden by RFC).

I would not go to the third option (you say it is not forbidden by RFC, @peacekeeper's review says the opposite, so is current practice...). Using a mixture of hyphen and plus sign is indeed an option.

One of the points of the + is to have a fallback, from a more-specific (and typically, newer) format to a less-specific (and typically, older) format -- so ld+json lets software that understands JSON-LD treat that file as such, while software that only understands JSON can ignore the ld+ aspect and work only with the json (albeit with less functionality); similar to application/rdf+xml.

That is all correct. However, for this specific case, a JSON-LD processor _does_ function with any JSON dialect, ie, something like did-ld+json would work, too. (Although it is not 100% clear to me how it would 'recognize' an incoming pure JSON file as JSON-LD. @dlongley should know much better than I will ever do:-)

Alternatively, we might pursue registration of application/jsonld as an alias of application/ld+json, such that we could then register application/did+jsonld ...

I would exclude this option. This WG is not chartered to act on behalf of a Recommendation "owned" by another WG.

[peacekeeper]

I would not go to the third option (you say it is not forbidden by RFC, @peacekeeper's review says the opposite, so is current practice...)

Hmm I don't think I said the opposite? I agree application/did+ld+json would work, and I actually like it quite a bit. All I did in my previous comment https://github.com/w3c/did-spec/issues/1#issuecomment-545337086 was to add application/did-ld+json as an additional option to the thread.

[iherman]

Oops, I misread your original comment https://github.com/w3c/did-spec/issues/1#issuecomment-545337086, @peacekeeper, my apologies.

[iherman]

However... if I follow @peacekeeper's interpretation, this means that did+ld+json would still have json as its suffix. In some way, it would mean, logically, something like (did+ld)+json, which may not be the message we want to convey. Applications looking for the 'main' syntax would still find json and not json-ld...

[TallTed]

The DID WG could reasonably "pursue" the registration of application/jsonld or other alias by raising that need to the JSON-LD WG, not necessarily directly with IANA. I think this need would fall among "specific usability or technical issues based on the community’s experiences" and so into their charter.

As things stand, the "main" syntax of JSON-LD is JSON, and therefore the "main" syntax of any syntax built off of JSON-LD would also be JSON. If JSON-LD is now mature and with sufficient adoption to be considered a "main" syntax in its own right, then application/jsonld or similar is definitely called for, as did+ld+json is unlikely to be the last such derivative/descendant syntax.

[iherman]

_If_ did+ld+json is acceptable to IANA, then this may be, after all, the best solution. I have looked at this issue with others and, indeed, there is no rule in the RFC-s against it although there is no precedence.

Personally, I would not want to go down the jsonld line for the reason above: it is not in the charter of this WG to do this. We can try to submit the did+ld+json when the FPWD is out and, well, see what happens... At the end of the day, it is up to IANA to accept it (or not).

[msporny]

Personally, I would not want to go down the jsonld line for the reason above: it is not in the charter of this WG to do this.

Agreeing w/ everything @TallTed said, and...

Yes, the DID WG should probably not do a application/jsonld registration... but we do have an active JSON-LD WG and it would be trivial for them to do it.

That said, we'd have to overcome this hurdle:

What would the file extension for application/jsonld be? .jsonld is already taken. What would a system do when negotiating for a JSON-LD document, accept both application/ld+json and application/jsonld? Unfortunately, I think we've painted ourselves into a corner with application/ld+json. The right thing to do, in hindsight, was application/jsonld. We didn't do that, so we're sort of stuck with application/ld+json unless we can figure out a way around the file extension and the backwards compatibility problems. I think we can suggest something sane wrt. backwards compatability... I can't think of a simple solution to the file extension issue.

[TallTed]

I think we've painted ourselves into a corner with application/ld+json

There is precedence for Media Type deprecation (search for DEPRECATED) or obsolescence (search for OBSOLETED) and replacement.

There is also precedence for multiple Media Types mapping to one filename extension (so application/jsonld could also map to .jsonld and vice versa) -- and for multiple filename extensions mapping to one Media Type, for that matter. See MimeTypeMap for some evidence of this, e.g. --

                {".3g2", "video/3gpp2"},
                {".3gp", "video/3gpp"},
                {".3gp2", "video/3gpp2"},
                {".3gpp", "video/3gpp"},

and

                {"image/png", ".png"}, //Defined in [RFC-2045], [RFC-2048]
                {"image/x-png", ".png"}, //See https://www.w3.org/TR/PNG/#A-Media-type :"It is recommended that implementations also recognize the media type "image/x-png"."

[iherman]

Yes, the DID WG should probably not do a application/jsonld registration... but we do have an active JSON-LD WG and it would be trivial for them to do it.

This is a last minute request that you could raise with the JSON-LD WG. Last minute, because the plan is to go to CR in the coming weeks, and this would be a substantial change (the processors should understand this extra media type, too).

At this point my vote goes for trying did+ld+json and see whether IANA accepts that.

[TallTed]

At this point my vote goes for trying did+ld+json and see whether IANA accepts that.

Which would leave us high and dry, if IANA doesn't like it for whatever reason, because by that time, JSON-LD WG may well be done and gone.

Some things are well kept isolated; some things require working in tandem. I think this falls into the latter group -- that if we are going to pursue application/did+ld+json with IANA, this should be in parallel with JSON-LD WG pursuing application/jsonld, with both applications referencing the other -- i.e., that only one application is meant to succeed, and that application/jsonld is preferred.

We have crossover membership with JSON-LD WG; I think (hope) those folks have sufficient understanding of the two work spheres to shepherd this along.

[iherman]

@TallTed I have raised it as an issue over there: https://github.com/w3c/json-ld-syntax/issues/287

That being said: the WG has declared feature freeze a while ago and has now a hard internal deadline for freezing the document. It is not only a matter of registration; the JSON-LD API document must be modified as well, to add a reference to this media type alongside the current ones, and processors must be modified as well.

[TallTed]

@iherman - Caveats understood; this is a non-trivial change, in all ways, and its timing is suboptimal at best. Still, it will be beneficial overall, and I expect all concerned parties will reach that conclusion after full consideration, which I hope may happen quickly.

[iherman]

See https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-25-json-ld#section3-2 (JSON-LD WG Meeting Minutes)

[azaroth42]

Dear DID WG,

As Ivan has said in the thread above, we are ready to go to CR with just a little bit of administrivia, so this is about as suboptimal as it could possibly be. In order to move this forward as quickly as possible, we would like to invite you to our next WG call, Friday November 1st at 12 noon Eastern, with these call-in details (members only link).

It is our current belief, but also currently unsubstantiated, that the registration of a profile URI can be accompanied by a file extension registration. Thus our equally current stance is that application/ld+json;profile="some-uri-here" is the way to go, with the caveats that (a) we could be wrong about the file extension possibility, and (b) that it's much longer and more complex seeming than just a new media type. Before the call next Friday, we will try to gather details about (a).

Thanks!

[iherman]

This issue was discussed in a meeting of the JSON-LD WG.

• RESOLVED: Ask IETF if the JSON-LD media type registration can specify that it should be able to be used with additional +s, such as did+ld+json, with the intent to fallback to ld+json and then to json. If the answer is no, then we proceed with the profile pattern.
• RESOLVED: In IANA considerations, allow file extension registration with profile registration.
• RESOLVED: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type
• ACTION: contact IETF about the multiple pluses in the JSON-LD registration (Rob Sanderson)
  
  View the transcript

  
  Media Types for JSON-LD
  
  Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/287
  
  Ivan Herman: See related DID issue
  
  Rob Sanderson: the DID WG is looking for how to have a media-type, with a specific file extension
  
  … which would be recognized as a subtype of JSON-LD
  
  … What would happen with multiple + signs, like application/did+ld+json ?
  
  … Or should it be application/did+jsonld
  
  … Or could an extension be registered with a profile of application/ld+json?
  
  Gregg Kellogg: did anyone consider application/did-ld+json? Does it satisfy any of the concern?
  
  Ivan Herman: that was one of the options.
  
  Markus Sabadello: we want a specific mime-type, in order to have a file extension,
  
  … and also to be able to specify the semantics of fragments in our format.
  
  … Problem seems to be that we are defining a subtype of a subtype.
  
  Dave Longley: potential options: application/did-ld+json, application/did+ld+json application/ld+json;profile=URI, application/did+jsonld, application/did+json
  
  Markus Sabadello: The hyphen or the multiple-plus solutions would work I think.
  
  Rob Sanderson: about the extension, there was a discussion in the Annotation WG;
  
  … (-> see also a separate action https://github.com/w3c/json-ld-wg/issues/123 )
  
  … we checked with IETF and IANA (Mark Nottigham).
  
  … We asked if a file extension could be registered with a profile parameter,
  
  … without a new media-type.
  
  … The answer was yes, provided that the “media-type owner” acknowledge it.
  
  … In this case, the “media-type owner” is us (the JSON-LD WG).
  
  … To me, the profile pattern is the preferable way. We should explore this first.
  
  Rob Sanderson: It would look like: application/ld+json;profile="https://w3.org/ns/did" (or whatever URI)
  
  Rob Sanderson: Profile parameter: https://www.w3.org/TR/json-ld11/#iana-considerations
  
  Benjamin Young: https://tools.ietf.org/html/rfc6906 - The ‘profile’ Link Relation Type
  
  Benjamin Young: https://tools.ietf.org/html/rfc7284 - The Profile URI Registry RFC
  
  Rob Sanderson: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml - Profile URI registry:
  
  Ted Thibodeau Jr: Can anyone point to a documentation of the profile suffix on mime-types?
  
  … We have been discussing the “+” solution, because it allows a fallback.
  
  … But according to the RFC, only the final + matters for this fallback mechanism.
  
  … But we hope that implementations consider all + signs,
  
  … otherwise, application/did+ld+json would fallback directly to JSON,
  
  … which is not ideal.
  
  … I would suggest that application/jsonld be declared, as an “alias” to application/ld+json,
  
  … i.e. having the same file extension.
  
  Ivan Herman: See reference to the ‘+’ descriptions
  
  Dave Longley: the JSON-LD should advertise the possibility to associate file extensions to profiles,
  
  … but the tooling is missing for properly working with the profile approach. (e.g., npm mime package)
  
  Markus Sabadello: about the fragments,
  
  … the way we are using the fragments in DID should be compatible with the way they are used in JSON-LD,
  
  … so the fallback mentioned above should work to some extent.
  
  … A pure JSON-LD tool should be able to process the fragments in a DID document.
  
  Dave Longley: +1 we absolutely want it to process the fragment the same way
  
  Ivan Herman: I don’t think the fragment ID is defined for the JSON format, is there one for JSON-LD?
  
  Gregg Kellogg: I think we say they have the same semantics as in RDF.
  
  “Fragment identifiers used with application/ld+json are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS].”
  
  Benjamin Young: JSON does not have fragment identifiers.
  
  Gregg Kellogg: is there inheritability of fragment identifiers across media-types?
  
  … It would be logical.
  
  Ted Thibodeau Jr: application/did-ld+json would need to echo much of application/ld+json
  
  Ted Thibodeau Jr: application/did+ld+json could inherit if MIME RFC made all + important
  
  Ted Thibodeau Jr: application/did+jsonld would inherit/fallback to application/jsonld
  
  Rob Sanderson: as TallTed pointed out, there is some time pressure.
  
  … We are close to recommendation.
  
  … Would some of the options require a normative change in JSON-LD?
  
  … Consensus seems to be that we should say, in the IANA section,
  
  … that profile IRIs can be associated to new file extensions.
  
  … did[+-]ld+json would not require any change.
  
  … did+jsonld would require a change.
  
  … Let’s focus on the options requiring some change.
  
  Dave Longley: could the application/ld+json registration possibly talk about additional ‘+’s? or would that be too out of scope?
  
  Ted Thibodeau Jr: application/jsonld parallel to application/ld+json with the latter preferred for basic JSON-LD would work … only derivatives of JSON-LD (like DID) would use the former … but maybe did-ld should be considered as parallel to ld as derivatives of JSON
  
  Ivan Herman: the registration of did+ld+json only concerns the DID WG, won’t affect the JSON-LD WG.
  
  … re: did-ld+json, my impression is that this mime-type would be considered independent from ld+json
  
  … The reason why it came up, if I’m correct, was to define the semantics of fragment identifiers.
  
  … We just pointed out that JSON-LD does define a semantics for fragment identifiers.
  
  … Is DID compatible with it? If not, then it should not be a subtype of ld+json,
  
  … regardless of the possibility for IANA.
  
  Markus Sabadello: +1, in DID documents we want to use standard JSON-LD fragment behavior
  
  Dave Longley: for me, they should be compatible, and I think this is the opinion of the DID WG.
  
  … I wonder if we could not just mention in the IANA declaration, that +ld+json should be considered a subtype of ld+json,
  
  … even despite what the RFC says about the final +.
  
  Rob Sanderson: We can ask IANA what they would think about that if we did that.
  
  Ted Thibodeau Jr: concerned about timing
  
  Markus Sabadello: I agree with Dave about the standard fragment semantics.
  
  Rob Sanderson: dlongley, you mentioned problems with the tooling for the profile approach.
  
  … can tools be updated more quickly than specs?
  
  Dave Longley: I’m not sure they can.
  
  … There are many toolchains out there…
  
  Ted Thibodeau Jr: if the only concern is the fragment semantics,
  
  … and they appear to be in synchrony,
  
  … do we need a DID media-type in the 1st place?
  
  Dave Longley: we also want a file extension.
  
  Ted Thibodeau Jr: multiple file extensions can be associated with a single media-type.
  
  … Why not associate the .did extension to application/ld+json?
  
  Rob Sanderson: this would be a bad precedent
  
  Ted Thibodeau Jr: there are lot of things out there, sharing the same media-type,
  
  … with very different contents.
  
  Benjamin Young: I’m assuming you want a file extension so that desktop apps do the right thing (double click)./
  
  … Most application do not trust only the extension, and check the content once opened.
  
  … We could register several extensions with application/ld+json, applications should still check the content.
  
  … The same problem exists with JSON.
  
  Markus Sabadello: we also want to be able to do content negotiation
  
  … we want to be able to distinguish btw a DID document and another JSON-LD document.
  
  Rob Sanderson: can we update the IANA section, saying that
  
  … when a file extension is associated with a profile,
  
  Ivan Herman: this discussion started with the question about multiple +. Shouldn’t we go back to checking this? If we can, this is the simplest solution.
  
  … Let’s check with Heather (from IETF). If the answer is no, then we can look for another solution.
  
  Dave Longley: +1 to ivan
  
  Benjamin Young: +1 to ivan
  
  Gregg Kellogg: +1 to ivan
  
  Ted Thibodeau Jr: did+ld+json conforms to RFC. but tools will probably fall back to json, not to ld+json. which may be OK.
  
  Markus Sabadello: but my understanding is that did+ld+json would NOT automatically inherit from ld+json
  
  Rob Sanderson: We could require that the registration of a file extension be combined with the registration of a profile URI. Then there’s the express intent of the profile URI and the extension being linked. Then the registration for ld+json would explicitly inherit all of the file extensions of all of the profiles.
  
  … the RFC says that only the last + is relevant.
  
  … I agree that we should check. I’m afraid the answer is no.
  
  Ivan Herman: Let’s ask, and prepare a fallback plan.
  
  Rob Sanderson: I think the fallback should be profile.
  
  Benjamin Young: the did+ld+json IANA declaration could explicitly state that it inherits ld+json.
  
  Proposed resolution: Ask IETF if the JSON-LD media type registration can specify that it should be able to be used with additional +s, such as did+ld+json, with the intent to fallback to ld+json and then to json. If the answer is no, then we proceed with the profile pattern. (Rob Sanderson)
  
  Gregg Kellogg: +1
  
  Dave Longley: +1
  
  Rob Sanderson: +1
  
  Pierre-Antoine Champin: +1
  
  Ivan Herman: +1
  
  Benjamin Young: +1
  
  David I. Lehn: +1
  
  Ted Thibodeau Jr: +1
  
  Ted Thibodeau Jr: worst case, did+ld+json is equivalent to did-ld+json … and things need to be explicitly and/or redundantly stated in the DID space.
  
  Ted Thibodeau Jr: this should require less retooling than reliance on profile – which currently only works in conneg
  
  Resolution #2: Ask IETF if the JSON-LD media type registration can specify that it should be able to be used with additional +s, such as did+ld+json, with the intent to fallback to ld+json and then to json. If the answer is no, then we proceed with the profile pattern.
  
  Markus Sabadello: if the answer is no in general, we can decide later if we go for the profile pattern, or something else…
  
  Markus Sabadello: +1 to above proposal, but fallback could still be either profile, or did+ld+json
  
  Action #1: contact IETF about the multiple pluses in the JSON-LD registration (Rob Sanderson)
  
  Benjamin Young: https://tools.ietf.org/html/rfc7231#section-5.3.2
  
  Dave Longley: the did+ld+json is legal; even if IETF decides that it does NOT inherit ld+json in general, we can bake this inheritance in this specific media-type
  
  Benjamin Young: we should check JS libraries, see how they handle this
  
  Ted Thibodeau Jr: JSON-LD WG could suggest that unrecognized /…+ld+json be treatable as /ld+json
  
  … (this could be non-normative at this point)
  
  Dave Longley: +1 to TallTed
  
  Benjamin Young: +1 to TallTed
  
  Markus Sabadello: +1 to TallTed
  
  Rob Sanderson: re. TallTed suggestion, it boils down to what IETF thinks of that pattern
  
  Ted Thibodeau Jr: even if they disagree about it in general, we can still recommend it for JSON-LD
  
  Gregg Kellogg: +1 to pchampin
  
  Markus Sabadello: +1 to pchampin
  
  Dave Longley: +1
  
  Ted Thibodeau Jr: We could recommend that JSON-LD processors process application/+ld+json
  
  Proposed resolution: In IANA considerations, allow file extension registration with profile registration. (Rob Sanderson)
  
  Rob Sanderson: +1
  
  Pierre-Antoine Champin: +1
  
  Gregg Kellogg: +1
  
  Dave Longley: +1
  
  Markus Sabadello: +1
  
  Ivan Herman: +1
  
  Resolution #3: In IANA considerations, allow file extension registration with profile registration.
  
  *Proposed resolution: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type* *(Rob Sanderson)
  
  Dave Longley: +1
  
  Markus Sabadello: +1
  
  Gregg Kellogg: +1
  
  Rob Sanderson: +1
  
  Pierre-Antoine Champin: +1
  
  Ivan Herman: +1
  
  Ted Thibodeau Jr: +1
  
  Resolution #4: Conforming json-ld processors SHOULD treat *+ld+json in the same way as the application/ld+json media type
  
  Benjamin Young: +1
  
  Rob Sanderson: I hope we get a response from IETF for next week.
  
  Benjamin Young: +1
  
  Ivan Herman: anyway, we can put in the document what we have resolved, regardless.
  
  Dave Longley: +1 this works regardless
  
  Markus Sabadello: thank you all for taking the time today!
  
  

[msporny]

I propose we do the following:

Create a MIME Type Registration in the specification with the following two MIME Types:

• application/did+json -- for non-JSON-LD DID Documents
• application/did+ld+json -- for JSON-LD DID Documents

[iherman]

(This is just for the records because it was discussed in the thread).

JSON-LD is now in CR, and its IANA considerations section includes the following:

Other specifications MAY create further structured subtypes by using +ld+json as a suffix for a new base subtype, as in application/example+ld+json. Unless defined otherwise, such subtypes use the same fragment identifier behavior as application/ld+json.

The new version of the application/ld+json has not been blessed by IANA, it was officially submitted a few weeks ago. We should probably wait with the resolution of this issue until we get a final agreement from IANA to see whether, in our case, application/did+ld+json would be acceptable. (Note that we have not received any negative comments on this yet.)

Note also that the same section says:

All other [profile] URIs starting with http://www.w3.org/ns/json-ld are reserved for future use by JSON-LD specifications

Ie, the profile option would also be available as a fallback in case IANA opposes xxx+ld+json.

[iherman]

Create a MIME Type Registration in the specification with the following two MIME Types:

• application/did+json -- for non-JSON-LD DID Documents
• application/did+ld+json -- for JSON-LD DID Documents

I'm o.k. with that (with the caveat in https://github.com/w3c/did-core/issues/1#issuecomment-583705298) but shouldn't we add, eventually, application/did+cbor?

[msporny]

I'm o.k. with that (with the caveat in #1 (comment)) but shouldn't we add, eventually, application/did+cbor?

Yes, but I know of no one that has a CBOR encoding at present... it's more of a thought experiment... and then there is the potential "+ld+cbor" for CBOR-LD, which has yet to materialize. My expectation is that a normative CBOR representation doesn't survive the DID WG and we'll end up referring to it in a non-normative way... and the IANA registration for did+ld+cbor and did+cbor won't exist in DID Core v1.0.

[msporny]

There is now a PR to address this issue: PR #196 -- merging that PR will automatically close this issue.