Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-18.txt

From: [email-masked]
Date: Mon, 05 Sep 2016 19:30:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names, Revised of the IETF.

        Title           : Uniform Resource Names (URNs)
        Authors         : Peter Saint-Andre
                          John C Klensin
	Filename        : draft-ietf-urnbis-rfc2141bis-urn-18.txt
	Pages           : 40
	Date            : 2016-09-05

Abstract:
   A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
   that is assigned under the "urn" scheme and a particular URN
   namespace, with the intent that the URN will be either a persistent,
   location-independent resource identifier or in some cases an abstract
   designator that is persistent but that does not identify a resource.
   With regard to URN syntax, this document defines the canonical syntax
   for URNs (in a way that is consistent with URI syntax), specifies
   methods for determining URN-equivalence, and discusses URI
   conformance.  With regard to URN namespaces, this document specifies
   a method for defining a URN namespace and associating it with a
   namespace identifier, and describes procedures for registering
   namespace identifiers with the Internet Assigned Numbers Authority
   (IANA).  This document obsoletes both RFC 2141 and RFC 3406.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-18

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Leonard <[email-masked]>
Date: Sun, 25 Sep 2016 16:41:59 -0700

Hello:

I read through draft-18.

Overall I do not have any negative feedback that requires blocking this document. It’s been a long slog; I think this document is getting very close to the next stage (i.e., last call, publishing, shutting down WG). Thanks all for the hard work.

***

r-component and q-components are now ordered: r first, then q. That is great with me. Thanks for accepting the suggestion.

Section 2.3.1 doesn’t specifically call out the parsing problems associated with "?=" being not possible to put in r-component, because it delimits the q-component; however, this is implicit in paragraph 3 (“The r-component ends with a "?=" sequence (which begins a q-component) or a "#" character (number sign, which begins an f-component).” I am okay with this.

However, the ABNF should make this clear. Right now it says:

 	      r-component   = pchar *( pchar / "/" / "?" )	

But that is ambiguous with ?= . It should say:

 	      r-component   = pchar *( pchar / "/“ /
   ("?" ( unreserved / pct-encoded / "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / ":" / "@" ) ) )

This is ? pchar without the = character.

I still believe that it’s better to say that r-component is the first ? , while q-component is the second ? , and simply say that r component can’t contain ? . But I already raised that issue repeatedly, and I acknowledge that there is some value in using ?X syntax, simply because it opens the door to other delimiters such as ?- ?! ?$ etc. (in which case, maybe it should just be "?" (unreserved / pct-encoded), leaving out all of the delimiters ).

***

I am fine with the technical result of URN-Equivalence (Section 3). However, I find the wording to be quite convoluted. From the specific to the more general:

“Two URNs are URN-equivalent if their <assigned-name> portions are
   octet-by-octet equal after applying case normalization (as specified
   in 
Section 6.2.2.1 of [RFC3986]) to the following constructs:” 

Actually I think that Percent-Encoding Normalization is meant to be referred to, possibly including case normalization to the pct-encoded productions.

Path Segment Normalization is not discussed (RFC 3986 6.2.2.3) but I think this is an important issue since we are allowing / in the NSS. Specifically what is:

urn:foo:abc/def/ghi/.././jkl

?

And is it URN-equivalent to:

urn:foo:abc/def/jkl

or not? And is it URN-equivalent to:

urn:foo:abc/d%65f%2f/jk%6c

? Why or why not?

The character encoding of the NSS is UTF-8, but this is not called out in the URN-Equivalence part. Tell me: if the NSS includes %FF, is that URN-equivalent to another one that includes %FF? 0xFF can never appear in UTF-8 content. Therefore, it is not a valid URN, and cannot be equal to another URN. But do we impose this on the equivalence algorithm or not? It’s better to say one way or another.

The text says to do an octet-by-octet comparison, but after normalizing 3 different parts (plus several other implied parts, see above) in differing ways. Why doesn’t the text just say:
  for a valid URN [implies UTF-8, implies conformance to ASCII-only, etc.], compare the scheme case-insensitively, the NID case-insensitively, and the NSS case-sensitively

? Etc.

Can a namespace create a distinction between percent-encoded characters and non-percent-encoded characters? RFC 3986 says it can’t for the unreserved characters, such as %6c = l . But the current text implies that it can (because it doesn’t say to do percent-encoding normalization). In contrast, what about gen-delims such as %2f = / and %3a = : , which can appear in both pct-encoded and non-encoded forms?

It appears that Unicode normalization issues/forms (NFC, NFD...) are not specifically discussed in this document. I would like to see that issue addressed by new registrations. Currently Section 6.4.2 merely hints at it in parts 2, 3, and 4. I would like to see the repertoire of characters be listed in the registration, along with the normalization forms, if relevant. For example, if a URN namespace is based on some French standard that allows é, ê, etc., then there should be some discussion about whether é is going to be U+00E9, U+0065 U+0301, or something else.

***

For similar nomenclature reasons, I am uncomfortable with the distinction between “URN” and “assigned-name”. See Section 1.2 and the use throughout the document. Basically, these two appear to be the same to me. What is the distinction?

Also, both the abstract and Section 1 say:

“A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
   that is assigned under the "urn" scheme and a particular URN
   namespace, with the intent that the URN will be either a persistent,
   location-independent resource identifier or in some cases an abstract
   designator that is persistent but that does not identify a resource.” 

“A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular
   URN namespace, with the intent that the URN will be either a
   persistent, location-independent resource identifier or in some cases
   an abstract designator that is persistent but that does not identify
   a resource.”

If a URN is a URI that is assigned under the “urn” scheme…then it would seem that a “URN” includes the r, q, and f-components. Because urn:foo:bar?+r-component?=q-component#f-component is a URI. Therefore, it is a URN. But I think an important distinction is trying to be made between the NAME component, which is urn:NID:NSS, and the entire URI, which includes r, q, and f. This distinction is muddled in the text.

Regards,

Sean

PS I just read Henry Thompson’s feedback. It doesn’t change my opinion of draft-18’s “done-ness” but I want to respond to that separately.

> On Sep 5, 2016, at 7:30 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn