Subject: [urn] Full review of urnbis-15

From: Sean Leonard <[email-masked]>
Date: Sun, 21 Feb 2016 07:41:12 -0800

This is a full technical review of urnbis-15.

While Section 1.1 Specificity and This Standard feels long-winded, I can 
at least appreciate and applaud the attempt to grapple with the tensions 
that have plagued this work. For the final publication, this section 
should be made more concise. Of these paragraphs:

The first paragraph is a bit convoluted but I agree with the technical 
content.

The second paragraph is  convoluted and tries hard to thumb off what 
"resolution" means. In this regard, it only adds vagueness without 
substantial technical merit. There is no such thing as "URL resolution", 
at least from the standpoint of RFC 3986. There is only URI 
dereferencing. Section 1.2 Terminology needs to precede Section 1.1 
Specificy and This Standard, because Section 1.2 actually discusses 
resolution versus dereferencing, and introduces the concept of URL as 
distinguished from the generic RFC 3986 URI case.

Paragraph 3 is technically on the money. I believe an example either in 
Paragraph 3 or in Section 2.2 (or in its own section) would be helpful. 
Consider: when encoding a whole number (i.e., nonnegative integer), the 
URN namespace can encode the number 65535 as:
urn:foo:65535
urn:foo:FFFF
urn:foo:ffFf
urn:foo:177777
urn:foo:６５５３５    (not actually in a URI protocol slot--this would 
be in a IRI protocol slot)
urn:foo:%EF%BC%96%EF%BC%95%EF%BC%95%EF%BC%93%EF%BC%95

The point being...URN constrains the representation and encoding of the 
unique identifier, but the namespace still has wide latitude to map the 
identifier to ASCII or Unicode code points, so long as that mapping is 
deterministic and bijective.

At the same time, Paragraph 3 is a bit overstated. The main problem is 
in NSS. NID is ASCII-only. As of draft-15, resolverID is also ASCII-only 
(unless you plan on encoding something in Punycode!), and r-component 
appears to be a cop-out. We can't help f-component or q-component 
because the URI spec governs those.

Paragraph 4 is an extremely long sentence. It can be made more concise, 
or removed for publication.

***
I agree that "described in [RFC2483]" is better than "defined in 
[RFC2483]", as it implies that RFC 2483 is on-the-out (although, out of 
scope for this WG).
***

This is an editorial comment with technical implications:
Section 2 says "...extend the URN syntax to natively allow characters 
outside the ASCII range..."
"to natively allow" is a split infinitive. Put "natively" somewhere else 
in that sentence.
That being said, the technical implication is that URN syntax could--in 
a different world--"natively allow characters outside the ASCII range". 
I do not know what is native and what is non-native. Since we are 
talking about changes since RFC 2141, I do not perceive this 
specification is doing anything really different. I would axe this 
paragraph entirely. What matters is the technical content of Section 2.2 
NSS regarding UTF-8.

The technical changes about q-component and r-component warrant their 
own e-mail.

Section 2.3.3: f-component
The changes are fine, except for one thing:
The f-component MUST NOT be passed to resolution services ->
Clients SHOULD NOT pass f-components to resolution servers unless [...]

I see what is trying to be done here. At the same time, I think that it 
fudges on the component model. Look, you can make a web browser that 
operates on the "client side" (where the client retrieves the HTML and 
image bits from the Internet, and then turns them into pixels on a 
display) or on the "server side" (where the server retrieves the HTML 
and image bits, turns them into pixels, and then blits them to a remote 
viewer over the Internet, whether that is a low-power device or a remote 
desktop or some kind--even if that blitting protocol runs over HTTP). 
That does not really affect the constituent protocols of web browsers 
(HTTP, HTML, image formats, WebSockets, etc.).

Resolution services should be defined as those components that take the 
relevant parts of a URN and transform the data into "resolved" results. 
The relevant parts of the URN are the NID, NSS, and r-component. 
Irrelevant parts of the URN are q-component and f-component. Therefore, 
if a service happens to be implemented more comprehensively, it is like 
the web-browser-on-the-server that I indicated. The service has a URN 
resolver *component*, plus other *components* that are doing 
URN-to-resource things.

I would therefore stick with the -14 wording of "MUST NOT", and better 
define resolution services (or components) accordingly.

The registration sections (6 and 7) are okay.

Sean