Re: Use Case Examples for DID URL Parameter Formats

I don’t like this approach at all.

Isn’t the DID method already in the DID that it’s attached to? And what happens when you try to put parameters on a different method? And, most importantly, what happens when one method has a good idea and it propagates to other methods? So the foo-widget is copied from the foo method to the bar and qux methods, but it’s still called foo-widget because that’s what everyone’s code is scanning for and nobody wants to change it to scan for bar-widget and qux-widget, and of course nobody’s ever going to change it to just plain widget because if that kind of thing happened then we wouldn’t have x-www-url-form-encoded as a MIME type in use today (the x- is supposed to mean experimental, and yet decades later here we are).

— Justin

On Apr 6, 2019, at 3:37 PM, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:

On 4/6/19 1:49 PM, =Drummond Reed wrote:
*Method-specific parameter names*

One thought I had after the call was to require method-specific
parameter names to be prefixed with the DID Method to ensure no
collisions. It's a simple rule that removes the need for a centralized
parameter name registry. So, for example:

sov-foo
v1-bar
btcr-baz

The ones in the DID spec would not be prefixed:

service
path
lothor-destroyer-of-worlds
etc.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches