Skip to content
This repository has been archived by the owner on Oct 29, 2019. It is now read-only.

Is method-specific-id supposed to be equivalent to param-char? #223

Closed
aljones15 opened this issue Jun 10, 2019 · 1 comment
Closed

Is method-specific-id supposed to be equivalent to param-char? #223

aljones15 opened this issue Jun 10, 2019 · 1 comment

Comments

@aljones15
Copy link
Contributor

aljones15 commented Jun 10, 2019

method-specific-id = *idchar *( ":" *idchar )
idchar             = ALPHA / DIGIT / "." / "-" / "_"
param-char         = ALPHA / DIGIT / "." / "-" / "_" / ":" /
                     pct-encoded

if you remove the pct-encoded from param-char then method-specific-id appears to be equivalent to method-specific-id.

method-specific-id = *idchar *( ":" *idchar )

this line makes the 2 equivalent because method-specific-id does include ":" inside of it with 0 or more idchars.

hence a valid method-specific-id could be:
::::

  1. param-char is much easier to read as it uses Alternatives to describe it's strings.
  2. method-specific-id's sequence group seems like an artifact from when param-char and method-specific-id differed or perhaps is reserved for future use if it becomes necessary to make it different from param-char.

Basically we could define one rule for both method-specific-id and param-char and then specify that param-char should be pct-encoded.

method-specific-id = *did-char
did-char = ALPHA / DIGIT / "." / "-" / "_" / ":" /
param-char = did-char pct-encoded

additionally idchar is inconsistently named because the other ABNF rules are snake-case.

I guess it feels like idchar and param-char are/were supposed to be different strings, but it was generalized to the point that the two are effectively identical.

@jandrieu
Copy link
Contributor

Closing because we've moved it to the DID WG did-spec repo. https://github.com/w3c/did-spec

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants