- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Sun, 18 Feb 2018 22:00:55 -0800
- To: Markus Sabadello <markus@danubetech.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAAjunnaz5O1sdT=9Sk_PeW2UAO3y4SJX7svsN0jP6cCN2MCpcQ@mail.gmail.com>
Markus, I think your are correct, and that the first option you suggest is the best one. I'd tweak the rule name slightly to this: did-reference = did *[ ";" did-service ]* [ "/" did-path ] [ "?" did-query ] [ "#" did-fragment ] did = "did:" method ":" specific-idstring But your core point stands, which is that the did service name is not part of the DID itself. Thanks, =Drummond On Sun, Feb 18, 2018 at 5:04 AM, Markus Sabadello <markus@danubetech.com> wrote: > I implemented a parser for DID syntax based on the ABNF: > > https://github.com/decentralized-identity/universal-resolver/tree/ > master/implementations/java/uni-resolver-core/src/main/ > java/uniresolver/did > > And one piece of feedback I have is that perhaps we want to change this: > > did-reference = did [ "/" did-path ] [ "?" did-query ] [ "#" > did-fragment ] > did = "did:" method ":" specific-idstring *[ ";" service > ]* > > To: > > did-reference = did *[ ";" service ]* [ "/" did-path ] [ "?" > did-query ] [ "#" did-fragment ] > did = "did:" method ":" specific-idstring > > This wouldn't change the allowed syntax, only re-organize the rules, since > the "service" name isn't really part of the "DID" itself, or? > > Or we could also introduce an intermediary rule: > > did-reference = *did-service* [ "/" did-path ] [ "?" did-query ] [ > "#" did-fragment ] > *did-service* = did *[ ";" service ]* > did = "did:" method ":" specific-idstring > > Or: > > did-reference = *( did / did-service ) *[ "/" did-path ] [ "?" > did-query ] [ "#" did-fragment ] > *did-service* = did *";" service* > did = "did:" method ":" specific-idstring > > Markus > On 02/18/2018 12:51 AM, =Drummond Reed wrote: > > On Fri, Feb 16, 2018 at 10:18 AM, Manu Sporny <msporny@digitalbazaar.com> > wrote: > >> Hey Drummond, >> >> After much friendly yelling back and forth at DB HQ :), I think Dave >> Longley has convinced me that I'm overly concerned about the service ABNF. >> >> I still feel uneasy about it, but I think the onus is on those of us >> that are concerned to provide concrete examples of where everything >> falls apart and for those that are not concerned to demonstrate why the >> examples are not a problem. >> > > Yes, let's do this. > > >> >> Let's get this into an issue and take the conversation from there, but >> I'm less against the concept than I was yesterday, and here's why: >> >> The argument that was most compelling to me was that the service >> description goes in the "authority" section of the DID URL: >> >> did:METHOD:AUTHORITY?query2=param2&query2=param2#fragment >> >> Where AUTHORITY contains the service description. While ChristopherA is >> correct that things after METHOD are typically the purview of the >> AUTHORITY section, we're making an exception in this case because things >> starting at the path are typically service specific. So, we're basically >> saying, if you're going to do services in your DID Method, you MUST do >> them in this way... and we're putting that at the DID Spec layer. >> > > Exactly. > > >> >> Again, I find this a bit sloppy, > > > Ironically, having worked on URI-based specs (RFC 3986) for 15 years now, > I find it very elegant. But explaining why is probably more easily > discussed in person at RWOT. > > >> but don't have a better suggestion. We >> do what I was suggesting, which was to use ? or & because those >> typically go in a path AFTER the AUTHORITY section. >> > > Right. > > >> >> In any case, we need more examples of services and non-services >> expressed through a DID before we can really reach a conclusion on this. >> > > Happy to help prepare some to go over on the list or on RWOT. > > =Drummond > > >> >> -- manu >> >> -- >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: The State of W3C Web Payments in 2017 >> http://manu.sporny.org/2017/w3c-web-payments/ >> >> > > >
Received on Monday, 19 February 2018 06:01:39 UTC