- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Thu, 4 Apr 2019 12:28:08 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAAjunnYmXYhtF4m2TMAipyKK6onumvMo3yK9OLZSOtaOw98LjA@mail.gmail.com>
On Thu, Apr 4, 2019 at 8:13 AM Manu Sporny <msporny@digitalbazaar.com> wrote: > On 4/4/19 5:43 AM, =Drummond Reed wrote: > > 1. The issue we saw with Manu's proposal is that there is no > > syntactic delimiter between the "naked DID" (that identifies the DID > > subject) and the parameters. > > The delimiter string between the "naked DID" and the parameters are > ":path:" and ":hl:", for the use cases produced thus far. > So I think the difference in our POV here is the difference between a "delimiter" (singular character) and a "delimiter string" (a sequence of characters). A parser can look for either. However if we are going to allow for what I'll call *colon-delimited parameters*, then that means a parser can never just look at a DID URl and pick out the bare DID in one step. Rather the parser is going to have to look at the DID URL and then compare all of the colon-delimited strings after the DID namespace string with its set of known colon-delimited parameter names in order to determine where the bare DID stops and parameters begin. As different DID methods start introducing their own colon-delimited parameter names that seems like an extensibility nightmare. However if we stick with a single universally defined delimiter character marking the end of the bare DID, then any parser immediately can immediately determine: 1. Where the bare DID ends 2. Are there any parameters? 3. How many parameters? 4. Do I understand what to do with the parameters? > I did not do one for type because we haven't heard of an example where > that is required, and if that existed, the processing rules would change > to "first search for an identifier, then search by type". So, if that > use case is important to folks, and it's not solved via an array of > service endpoints (which is simpler), then we still have a solution that > works. > > The other advantage is that we can still reserve the ";" for matrix > parameters in the future, if we need them, but at this point, we can > solve the use cases without using matrix parameters and thus keep the > syntax for DIDs simpler. > See my point above that if we allow colon-delimited-parameter names, we'll be stuck with them forever, so if we later switched to semi-colon delimited parameters, it would get really complex. =D > > > > -- > Manu Sporny (skype: msporny, twitter: manusporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Veres One Decentralized Identifier Blockchain Launches > https://tinyurl.com/veres-one-launches > >
Received on Thursday, 4 April 2019 19:28:43 UTC