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

Thanks for the correction, Joe - and being nice in doing so :-).  That's an
obvious one I shouldn't have said. Doh!

On Thu, Apr 4, 2019 at 10:01 AM Joe Andrieu <joe@joeandrieu.com> wrote:

> Stephen,
>
> This isn't quite accurate. For URLs, the fragment is the only part that is
> handled by clients post dereferencing.
>
> We do not currently have semantics for path and query parts for DIDs.
>
> For non-service pointing DIDs, there is literally no consensus on what to
> do with path and query parts.
>
> For service point DIDs, there is a use case for "file folder" applications
> where you have a large set of assets you wish to have portable, consistent
> access to, such as you might build a web page with local references and
> move it to a different domain and it all still works. The goal here is to
> do that WITHOUT changing the DID, but rather just the service endpoint.
>
> The blanket appending of path & query parts to service endpoints is
> problematic because the service endpoint itself could have path & query
> parts. So how do you amalgamate?
>
> did:ex:123;me/mypicture.png
>
> When I move from one service to another, e.g.,
> from http://twitter.com/JoeAndrieu to http://mystodon.andrieu.net?user=joe
>
> The append DID may have been valid at twitter
> http://twitter.com/JoeAndrieu/mypicture.png but is almost certainly NOT
> at mystodon: http://mystodon.andrieu.net?user=joe/mypicture.png
>
> So, for some use cases, appending will break the urls.
>
> On Thu, Apr 4, 2019, at 8:47 AM, Stephen Curran wrote:
>
> Daniel, that is available for the developer to use as the DID URL.
> However, it is to be processed by the client - post resolution.  The matrix
> syntax parameters enables information to be passed to the resolver, so that
> it can handled at resolution time.  So it is good for interacting with the
> ledger. In the Indy case - getting non-pure-DID-type data off the ledger
> (schema, creddef, rev reg) by the resolver with DID syntax.  Query params
> can be used after the data is back to the client.
>
>
>
> On Thu, Apr 4, 2019 at 8:39 AM Daniel Hardman <daniel.hardman@evernym.com>
> 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.
>
>
>
>
> --
>
> Stephen Curran
> Principal, Cloud Compass Computing, Inc. (C3I)
> Technical Governance Board Member - Sovrin Foundation (sovrin.org)
>
> *Schedule a Meeting: **https://calendly.com/swcurran
> <https://calendly.com/swcurran>*
>
>
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com
> +1(805)705-8651
> http://blog.joeandrieu.com
>
>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*