Re: A simpler approach to DID services and content-addressing

Dmitri has also explored this case, I'm quoting from Option 2 here
<https://github.com/w3c-ccg/did-spec/issues/90#issuecomment-439636972>:

Reasons not to go with this approach:

  * Not as easy for a DID Resolver to tell that this is a Service URI --
    it would have to first parse the DID and then examine the query
    params for /reserved keywords/ like |service| (which would not be
    allowed to be used in any other context), and only then pass it on
    to the code path that handled resolving service URIs.
  * More importantly, this approach goes against the URI spec. Query
    parameters (see Section 3.4 of the URI spec
    <https://tools.ietf.org/html/rfc3986#section-3.4>) are /scoped to a
    particular scheme and naming authority/. In other words, query
    parameters are only meaningful to a given server, and have no
    universal meaning across different URIs (even within the same URI
    scheme). Similarly, with hash fragments: /fragment's format and
    resolution is dependent on the media type/ and /Fragment identifier
    semantics are independent of the URI scheme and thus /cannot be
    redefined by scheme specifications/./

On 4/4/19 5:38 PM, Daniel Hardman wrote:
> Please forgive me if this question triggers remedial tutoring.
>
> Is there some important reason why we can't repurpose an existing
> convention? For example, could we just adopt the familiar syntax for
> query strings?
>
> did:example:1234abcd?a=b&c=d&e=f
> This has the advantage that every software stack on the planet
> probably already has code that can parse it, and every developer
> already knows it.