Fragment identifier semantics are independent of URI scheme

[burnburn]

Taken over from the CCG (w3c-ccg/did-spec#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 w3c-ccg/did-spec#82 (comment)).

[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 w3c-ccg/did-spec#82 (comment)) 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 #1 (comment) was to add application/did-ld+json as an additional option to the thread.

[iherman]

Oops, I misread your original comment #1 (comment), @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: w3c/json-ld-syntax#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]

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 #1 (comment)) 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.