Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review

["Roy T. Fielding" <[e-mail]>]

> On Apr 13, 2015, at 2:05 PM, John C Klensin <[e-mail]> wrote:
> 
> Roy,
> 
> I think I've having serious trouble with the position you are
> taking but, before I overreact (again?) and confuse things
> further, I would appreciate your clarifying something for me.
> 
> Let's put 2141bis aside for a moment and go back to 2141 itself.
> Section 2 of 2141 says (trimming irrelevant material):
> 
> 	All URNs have the following syntax [...]:
> 
>       <URN> ::= "urn:" <NID> ":" <NSS>
> 
> 	The Namespace ID determines the _syntactic_
> 	interpretation of the Namespace Specific String (as
> 	discussed in [1])."
> 
> Reference [1] points to an I-D that I assume evolved into RFC
> 2276.
> 
> 2141 then goes on to say:
> 
>   <NSS>   ::= 1*<URN chars>
>   <URN chars> ::= <trans> |
>        "%" <hex> <hex>
>   <trans> ::=  <upper> | <lower> | <number> | <other> |
>        <reserved>
>   <hex>   ::= <number> | "A" | "B" | "C" | "D" | "E" |
>       "F" | "a" | "b" | "c" | "d" | "e" | "f"
>   <other>  ::= "(" | ")" | "+" | "," | "-" | "." |
>       ":" | "=" | "@" | ";" | "$" | "_" | "!" | "*" | "'"
> 
> Note that, if fragments (or anything delimited by a leading "#")
> were allowed, the above would make them part of the NSS.  If I
> understand you correctly, that is invalid because, in the syntax
> of 3986, the 2141 NSS is necessarily a substring of hier-part,
> while 3986 appears to allow "#" (and a fragment) only after the
> hier-part.  Is that correct?

Umm, not sure I understand the question.  The syntax above should not allow
a fragment delimiter "#" to be part of the NSS, which should mean that the <URN>
would match the absolute-URI production of 3986.  In other words, it would be
valid if it excludes the fragment.

  http://tools.ietf.org/html/rfc3986#section-4.3

> And, in section 2.3,
> 
>   The reserved character set is:
> 
>   <reserved>    ::= '%" | "/" | "?" | "#"

And there is the bug.  In RFC1808 and RFC2396, the "#" wasn't in the reserved set.
It was in the punctuation or delims set, which meant it was never allowed outside
of the specific occurrence as the fragment delimiter.  In RFC3986, the "#" is in
the reserved set, but the reserved set is for illustrative purposes only in both
2396 and 3986 (the URI grammar itself does not make use of the reserved production).

  http://tools.ietf.org/html/rfc2396#section-2.4.3

>   [...]
>  2.3.2 The other reserved characters
> 
>  RFC 1630 [2] reserves the characters "/", "?", and "#" for
>  particular purposes. The URN-WG has not yet debated the
>  applicability and precise semantics of those purposes as
>  applied to URNs. Therefore, these characters are RESERVED
>  for future developments.  Namespace developers SHOULD NOT
>  use these characters in unencoded form, but rather use the
>  appropriate %-encoding for each character.
> 
> Now, am I correct in my understanding that the above statement
> is invalid on its face because no URI scheme can prohibit the
> use of fragments, even to the extent of saying that they SHOULD
> NOT be used?

Yes.  More to the point, it should have said that they MUST NOT be
in NSS, since the fragment is not part of the URL, and they should have
been referring to RFC1808 (a proposed standard at that time), not
RFC1630 (an informational RFC).  In general, though, this was understood
and expected to be resolved as part of the development of RFC2396 and
finally in the form of RFC3986.  The IETF did a lot of work on URI
in the 18 years since RFC2141.

> Am I also correct in my understanding that the rule(s) that
> invalidate the above have nothing to do with any of 4395bis, RFC
> 4995, or even RFC 3986 but depend only on  RFC 1738 or possibly
> RFC 2396?

RFC1808, RFC2396, and RFC3986 (in succession).  We did have these discussions
about fragment, each time, which is why the requirement in RFC3986 (sec 4.3)
is very clear (IMO), and why it is repeated in 4395bis.  It is specified
that way because scheme-specific fragment is neither desirable (from the
architecture PoV) nor interoperable (most software separates the fragment
as part of reference parsing, before doing anything with the scheme).


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>