just to make it easier to see the issue I am copying the content here:

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:

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

param-char is much easier to read as it uses Alternatives to describe it's strings.
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.

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.

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

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions