Closed mwherman2000 closed 5 years ago
Fine w/ it being merged, note the editorial nits. Please mention if you plan to fix them or not. Fine w/ merge w/o them being fixed, but reserve the right to clean up the text later on (from an editorial perspective).
terms.html
, added the following sentence with link back to this section...
A DID is a URL, URI, and a URN.
I was just about to add that we really don't need that paragraph? I can't imagine any implementer caring about whether DIDs are URLs or URNs...
@dmitrizagidulin There's technical details/differences that matter. For example, https://github.com/w3c-ccg/did-spec/issues/97
@mwherman2000
There's technical details/differences that matter.
I'm not seeing it.. Issue #97 has nothing to do with whether DIDs are URLs or URNs, it has to do with JSON-LD parsing and serialization mechanics.
But anyways, hopefully the issue has been settled? That DIDs are emphatically not URNs, they do not start with urn:
, and do not match the URN RFC?
@mwherman2000
There's technical details/differences that matter.
I'm not seeing it.. Issue #97 has nothing to do with whether DIDs are URLs or URNs, it has to do with JSON-LD parsing and serialization mechanics.
But anyways, hopefully the issue has been settled? That DIDs are emphatically not URNs, they do not start with
urn:
, and do not match the URN RFC?
DIDs might not even be URIs as the current draft DID spec is trying to describe them ... see https://github.com/w3c-ccg/did-spec/pull/159#discussion_r251186233 ...unless we refactor the draft DID spec into a "identifier" spec separate from the "acesss/interaction" protocol spec ...in the same document or in separate spec documents. See https://github.com/w3c-ccg/did-spec/issues/121
The URL spec (referenced in the draft DID spec) is an interesting general pattern to consider: https://url.spec.whatwg.org/#urls
My favorite quote? :-)
A URL can be seen as the in-memory representation. (vs. what is a URL string)
I'd avoid the WHATWG URL spec. It's intended for browser/JavaScript parsing of values in src
and href
's. It's not a general foundation for identification like RFC 3986 (and related RFCs). I'd avoid it, unless you're building an HTML parser or JS runtime.
Spec restructuring and terminology clarification is progressing, and I think the various discussions in this thread are resolved enough to close this PR now.
Fixes #155 Fixes #156
Preview | Diff