Skip to content
This repository has been archived by the owner on Oct 29, 2019. It is now read-only.

Fragment identifier semantics are independent of URI scheme #82

Closed
msporny opened this issue May 14, 2018 · 5 comments
Closed

Fragment identifier semantics are independent of URI scheme #82

msporny opened this issue May 14, 2018 · 5 comments
Assignees
Labels
editorial Editorial changes to the specification

Comments

@msporny
Copy link
Contributor

msporny commented May 14, 2018

@gklyne wrote:

  1. DID fragments - the URI specification reserves the interpretation of fragment ids to the MIME type of a representation of the identified resource, and: "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." -- https://tools.ietf.org/html/rfc3986#section-3.5 I would suggest the fragment id interpretation maybe could be associated with a MIME type defined for the DID document?
@msporny msporny self-assigned this May 14, 2018
@msporny msporny added the editorial Editorial changes to the specification label May 14, 2018
@msporny
Copy link
Contributor Author

msporny commented May 14, 2018

Create a PR that adds a MIME Type registration section to the specification.

@peacekeeper
Copy link
Member

Do we need a new MIME type or use the existing application/ld+json ?

@msporny
Copy link
Contributor Author

msporny commented May 22, 2018

@peacekeeper wrote:

Do we need a new MIME type or use the existing application/ld+json ?

I expect we need a MIME subtype... application/did+ld+json (or something like that). If you don't do that, you have to come up with heuristics wrt. figuring out if you're actually dealing w/ a DID Document. The latter can be done, but it's not the recommended path for Web architecture.

@TomCJones
Copy link

What is the status of minetype

@msporny
Copy link
Contributor Author

msporny commented Sep 17, 2019

This issue has been transferred for processing by the DID WG.

@msporny msporny closed this as completed Sep 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
editorial Editorial changes to the specification
Projects
None yet
Development

No branches or pull requests

3 participants