Closed iherman closed 3 years ago
So per the current DID URL syntax, the following example would be valid:
did:example:123;service=agent/mypath?myquery#frag
In our DID URL ABNF, the part ;service=agent/mypath
would correspond to the path-abempty
rule.
Right now, in DID Core, we're not saying anything on how the part that's parsed as path-abempty
is used when dereferencing a DID URL, or what it means. The intention of the note is to reserve the right to say something about the use of ;
in the future. Therefore, developers and users should probably not construct and use DID URLs that contain ;
at this time. This doesn't mean the path-abempty
rule needs to be modified.
See also https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-04-07-did#resolution1.
Any ideas on how to improve the note?
Therefore, developers and users should probably not construct and use DID URLs that contain ; at this time.
Agree. @iherman -- we're just being nice and letting developers know that if they use ;
anywhere, that they should't be surprised in the future when we define it in a way that breaks their implementations. :)
Wouldn't it be better to make the note a little bit more explicit to avoid such misunderstandings? Something like:
Although the semicolon (;) character may be used according to the rules of the DID URL syntax, future versions of this specification may use it as a sub-delimiter for parameters as described in [MATRIX-URIS]. To avoid future conflicts, developers should avoid its usage.
What really bothers me is the formulation "This specification reserves". This specification, in the current formulation, does not do anything with the ';' character...
WDYT?
Wouldn't it be better to make the note a little bit more explicit
I like your improved language for this note, feel free to do a PR.
Done in #682 (with a slightly different wording at the end to avoid the duplicate usage of 'avoid').
PR #682 has been merged, closing.
In §3.2 there is a note that says:
But this is a note, i.e., it is non-normative. On the other hand, if one follows the specification chain in RFC 3986:
path-abempty -> segment -> pchar -> sub-delims, the last element on the chain does allow ';'. In other words, the normative text in our text does allow for the usage ';', and that is stronger than the note. Which makes the note, effectively, irrelevant.
I am not sure how exactly we want to handle that. Maybe by saying, in the normative text, that on that point, the path-abempty rule of the RFC is modified insofar as the ';' character is not allowed.