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

[John C Klensin <[e-mail]>]

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?

And, in section 2.3,

   The reserved character set is:

   <reserved>    ::= '%" | "/" | "?" | "#"

   [...]
  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?

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?

If any of that is not correct, could you please explain?

thanks,
    john


--On Friday, April 10, 2015 20:44 -0700 "Roy T. Fielding"
<[e-mail]> wrote:

>> On Apr 10, 2015, at 8:38 AM, Barry Leiba
>> <[e-mail]> wrote:
>> 
>>> No scheme can prohibit fragments. They are not part of the
>>> scheme's syntax.
>> 
>> We continue to have a confusion between syntax and semantics
>> here.
>> 
>> I absolutely agree that no scheme can say that fragments are
>> syntactically invalid, because the schemes do not control the
>> syntax of a URI.
>> 
>> But a scheme can certainly say that fragments make no
>> semantic sense within that scheme, and that if a URIs uses
>> that scheme and contains a fragment, it is not a well formed
>> URI within that scheme.
> 
> No, they can't, or at least they cannot say that truthfully.
>...