Re: DID 'service' ABNF

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 <mailto: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/
>     <http://manu.sporny.org/2017/w3c-web-payments/>
>
>