Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

[Peter Saint-Andre <[e-mail]>]

On 1/7/20 12:11 PM, John C Klensin wrote:

> Instead, I was trying to raise a far more narrow question: Given
> that RFC 3986 separates names and locators and that we have
> already had confusion about what is appropriate in URNs based on
> the language there, does this document make things worse?  I
> think it may.  Even a statement fragment (from the first
> paragraph of Section 3 and inherited from 7320) like "...as
> links that are exchanged as part of the protocol, rather than
> statically specified syntax" are inconsistent with the use of
> keyword values in some URN namespaces as static indicators. 

Indeed, it's not immediately obvious what a "protocol" would be in the
case of many URN namespaces, precisely because the URN is a name rather
than a locator.

> If
> you want to ask the slightly different question of whether, if
> RFC 7320 made things worse, does this I-D make things even worse
> than that, I don't have an easy answer except to note at least
> one example: The last paragraph of Section 2.3, which appears to
> be new, says
> 
>> Extensions MUST NOT define a structure within individual URI
>> components (e.g., a prefix or suffix), again to avoid
>> collisions and erroneous client assumptions.
> 
> But, as I understand that rule, it is precisely what some rules,
> and provisions for namespace-specific rules, in RFC 8141, do.

It's not clear to me whether a URN namespace counts as a 7320bis
protocol extension (which can "offer new capabilities that could apply
to any identifier, or to a large subset of possible identifiers");
however a definition of, say, URN r-components would probably fit the
bill, and such a definition might well define structures that would
violate the aforementioned MUST NOT.

> Again, the solution at this point appears to be either to be
> much more careful about binding the statements in the I-D to the
> concept of ownership or to indication that this specification
> does not apply to URNs (or, if preferred, to what 3986 describes
> as "name" URIs) at all.

That might be the best approach.

Peter