Register application/jsonld alongside application/ld+json?

[iherman]

This issue came up in the DID Working Group, as part of the discussion on how to define a media type for a DID document. Instead of repeating all the issues, please refer to https://github.com/w3c/did-spec/issues/1.

If accepted it should be done before CR, because that should be reflected in the API document as well.

[iherman]

This issue was discussed in a meeting.

• ACTION: find reference to file extensions for profiles re annotation (Rob Sanderson)
• ACTION: comment in issue inviting DID WG to JSON-LD WG regular call next week to discuss (Rob Sanderson)
  View the transcript

  pplication/jsonld issue #287
  Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/287
  Ivan Herman: am representing the DID WG
  … it is in that capacity that I raised this question
  Dave Longley: this might be better if people could rad over the DID spec issue first,
  … but it’s not clear how to handle mimetypes
  … this is documented at the discussion there (at DID)
  Pierre-Antoine Champin: the goal is to be able to declare application/did+jsonld?
  … ?
  Ivan Herman: Yes. It’s unclear whether application/did+ld+json is acceptable
  Dave Longley: no one does this^ … but it doesn’t seem illegal … and questionable what tools would do.
  Ivan Herman: there is no current registered mimetype that uses two + signs
  … so we are not sure if this is really possible
  Dave Longley: VC WG did not choose a mimetype
  Dave Longley: VCWG didn’t pick a MIME type that i can see
  Ivan Herman: that is a typical case where this might make sense
  Rob Sanderson: https://www.w3.org/TR/annotation-protocol/#annotation-retrieval
  Rob Sanderson: for Annotations, we went with a profile
  … you can trigger a file extension from a profile, says IANA. If so, that would fulfill the requirements listed on the DID issue comment
  … but I don’t have a reference for that
  … we would have to go search the minutes
  Rob Sanderson: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml
  Ivan Herman: we defined no extension for annotation
  Action #3: find reference to file extensions for profiles re annotation (Rob Sanderson)
  Rob Sanderson: if we did the application/jsonld, processors would have to know about it, which would be a normative change to the document
  Ivan Herman: it would change the documents to allow this new media type in parallel to the older one
  … it is simple for the document, but causes a lot of change elsewhere, because JSON-LD processors would have to change, too.
  Rob Sanderson: we aren’t going to decide this today
  … if there is no change here, we are on-track for CR
  … a change here would push CR back by at least 2 weeks with Thanksgiving looming
  Dave Longley: we want this group to enable other groups to be able to extend jsonld MIME type w/ file extension support – just a question of whether we need to register application/jsonld or not … either way should provide some advice to extenders on what to do
  Dave Longley: we did discuss this in the 1.0 days, but it might not recorded in issues
  Rob Sanderson: https://github.com/w3c/did-spec/issues/1#issuecomment-545103700
  Rob Sanderson: if you can register a file extension to a profile, than that is what we could recommend
  … how does application/jsonld solve the problem?
  Ivan Herman: because then you can do application/did+jsonld
  … no multiple plus signs
  Rob Sanderson: this came up in XML days (application/xhtml+xml)
  Ivan Herman: i couldn’t find any example of this (multiple plus signs) in IANA
  … if I have a doc that is application/did+ld+json, and a JSON-LD proc, then that proc should handle it fine regardless of the DID aspect.
  … if I do application/did+json, then a JSON-LD proc may or may not work correctly
  … (handle it as JSON-LD)
  Pierre-Antoine Champin: at the discussion at the DID WG, there is discussion of an alias
  … is this an official construct of IANA?
  Ivan Herman: I don’t know, but i think not; it just reflects that two media types may share suffix (but I may be wrong)
  … I propose that azaroth digs up the remark from IANA about file extensions and we’d come back to the issue
  Pierre-Antoine Champin: a profile approach could look pretty complicated to some people
  … it might be a shame, in terms of marketing
  Dave Longley: +1
  Rob Sanderson: dlongley, the two WGs can meet at the next JSON-LD WG meeting
  … to discuss this
  Action #4: comment in issue inviting DID WG to JSON-LD WG regular call next week to discuss (Rob Sanderson)
  

[gkellogg]

See my comment in the WG issue.

👎 to registering application/jsonld, if there is a way to avoid it. Registering with a profile parameter, or something like application/anno-ld+json would seem preferable. What happens if there are sub-profiles of anno, or some other sub-type?

Surely, we can't be the first format to run-into more than one-level of media-type sub-types.

[iherman]

This issue was discussed in a meeting.

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

[iherman]

I agree to close this.