This repository has been archived by the owner on Oct 29, 2019. It is now read-only.
Does the did-spec need to be specific about which parts of the URI RFC it is conformant with? #169
Labels
editorial
Editorial changes to the specification
Comments
|
Talk about how DIDs are conformant ... not if. There's some subtlies (sp) here:
I think @dmitrizagidulin has done a good/great job with the new DID ABNF syntax. CC: @talltree |
|
On Wed, Feb 13, 2019 at 4:11 AM Michael Herman (Toronto) < ***@***.***> wrote:
Talk about how DIDs are conformant ... not if. There's some subtlies (sp)
here:
1. DIDs can have a specific syntax specification that is structured
differently from the URI spec and still be 100% conformant. ... defined as
parsable by a URI parser.
2. This is different from DIDs supporting every possible syntax
"configuration" in the URI spec. Hope this clear ...it may not be.
I think Dimitri has done a good/great job with the new DID ABNF syntax.
CC: @talltree <https://github.com/talltree>
I was at IBM Think all last week so I haven't had a chance to review the
new DID ABNF syntax from Dimitri, but given how out-of-date the old one
was, I'm sure it's an improvement.
I'm going through the past week of CCG email, but in case I don't find it,
can you share a link to Dmitri's new version?
|
|
New abnf: #168
…On Sat, Feb 16, 2019, 21:12 Drummond Reed ***@***.***> wrote:
On Wed, Feb 13, 2019 at 4:11 AM Michael Herman (Toronto) <
***@***.***> wrote:
> Talk about how DIDs are conformant ... not if. There's some subtlies (sp)
> here:
>
> 1. DIDs can have a specific syntax specification that is structured
> differently from the URI spec and still be 100% conformant. ... defined
as
> parsable by a URI parser.
> 2. This is different from DIDs supporting every possible syntax
> "configuration" in the URI spec. Hope this clear ...it may not be.
>
> I think Dimitri has done a good/great job with the new DID ABNF syntax.
>
> CC: @talltree <https://github.com/talltree>
>
I was at IBM Think all last week so I haven't had a chance to review the
new DID ABNF syntax from Dimitri, but given how out-of-date the old one
was, I'm sure it's an improvement.
I'm going through the past week of CCG email, but in case I don't find it,
can you share a link to Dmitri's new version?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#169 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJ5VP2qIDhxYCCp2_D94QODdH_zpwOUNks5vONalgaJpZM4a4nrm>
.
|
|
Brent, thanks, I had just found it at the same time you sent your email.
I agree with Michael; Dmitri did a good job. (A nit is that I'd shorten
some of the rule names so the lines don't have to wrap, but that's a purely
editorial call that we can discuss in Barcelona.)
…On Sat, Feb 16, 2019 at 8:28 PM Brent ***@***.***> wrote:
New abnf: #168
On Sat, Feb 16, 2019, 21:12 Drummond Reed ***@***.***>
wrote:
> On Wed, Feb 13, 2019 at 4:11 AM Michael Herman (Toronto) <
> ***@***.***> wrote:
>
> > Talk about how DIDs are conformant ... not if. There's some subtlies
(sp)
> > here:
> >
> > 1. DIDs can have a specific syntax specification that is structured
> > differently from the URI spec and still be 100% conformant. ... defined
> as
> > parsable by a URI parser.
> > 2. This is different from DIDs supporting every possible syntax
> > "configuration" in the URI spec. Hope this clear ...it may not be.
> >
> > I think Dimitri has done a good/great job with the new DID ABNF syntax.
> >
> > CC: @talltree <https://github.com/talltree>
> >
> I was at IBM Think all last week so I haven't had a chance to review the
> new DID ABNF syntax from Dimitri, but given how out-of-date the old one
> was, I'm sure it's an improvement.
>
> I'm going through the past week of CCG email, but in case I don't find
it,
> can you share a link to Dmitri's new version?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#169 (comment)>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AJ5VP2qIDhxYCCp2_D94QODdH_zpwOUNks5vONalgaJpZM4a4nrm
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#169 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADLkTcPFXwCl6SxTeMh9hbGADDQYfopBks5vONp_gaJpZM4a4nrm>
.
|
|
As I understand it a DID URI should be conformant with the whole of RFC 3986. Therefore there is no need to add language about "which parts" (and therefore this issue can be closed). Does anyone disagree with that? |
|
Amy, right on, I agree.
…On Sat, Mar 30, 2019 at 3:59 PM Amy Guy ***@***.***> wrote:
As I understand it a DID URI should be conformant with the whole of RFC
3986. Therefore there is no need to add language about "which parts" (and
therefore this issue can be closed). Does anyone disagree with that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#169 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADLkTUI2LSN15DY9Q6-zKqRGBr_kDhrwks5vb-xFgaJpZM4a4nrm>
.
|
|
@mwherman2000 considering the current ABNF grammar in the spec (after merging #189), and considering the discussion in this thread, do you still see an open issue here?
|
|
It seems there was consensus on an approach in response to this issue and that an update to the ABNF was merged in based on that consensus. If there are still outstanding concerns, please raise a new issue in the DIDWG did-spec repo. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
...so we can avoid these types of conversations? #167 (comment)
TODO: Add an RFC 3986 specific section to the DID spec called "RFC 3986 Conformance".
The text was updated successfully, but these errors were encountered: