[urn] Where I think we stand

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

Hi.

I have read, but deferred responding to, the notes posted in the
last two weeks in the hope of getting a revised version of the
"separation" document together to reflect the "separate
semantics but preserve syntax and URN identity as part of the
URI family" conclusion I think we reached in Toronto.  As a
preview, I've changed the tentative title to reflect that
change: it now "URN Semantics Separate from Generic URIs".  If
anyone has a better idea, please suggest it.  I'm going to
describe it as "the separation draft" below and for the time
being.

The working draft version is now in the hands (or at least
mailboxes) of Andy, Barry, and Peter.   I'll post it as soon as
they give me the go-ahead or minutes are posted that I can check
the changes against.  Unless they advise/instruct otherwise, the
next version will be draft-ietf-urnbis-urns-are-not-uris-02 even
though that is not what it about any more.

One of my conclusions from both the recent email threads and the
Toronto discussions is that there is considerable disagreement
among usually-sensible people about what 3986 actually says.
Some of us believe the comparison "ladder" is sequential and
normative with the only important choice being how far one goes
up it, others that it is just a list of example types of
comparisons about which applications can reasonably pick and
choose.  Some of us see some of the examples as restrictive,
others as just examples and so on.  Either as a result of those
differences or for other reasons, some of us see 3986 as
semantic-laden, others see it as containing almost no normative
semantics but merely discussions of how some fields might be
used.

The observation that many (perhaps most) implementations of
generic URIs do not pay much attention to 3986's semantic
strictures (or specific URN syntax strictures there), but
instead either rely on 3986 syntax only or on syntax closer to
the "scheme:<stuff>" model doesn't "prove" those constraints are
not present (or that they are), only that we are even more
justified than we might be otherwise in pushing them aside (if
they exist) rather than feeling constrained by them.

I don't see any way to resolve those differences in readings
other than to make them irrelevant (which the "don't worry about
the semantics" approach seems to me about) or to do a complete
revision of 3986 that would eliminate any ambiguity.   To me,
there are three problems with the latter: it is far out of scope
for this WG, it would (at best) take a long time, and it would
require dealing with other groups who want to reinterpret or
obsolete 3986.  

Perhaps the important thing is that, if one believes that 3986
imposes constraints on things that the WG believes need to be
done with URN, then the separation draft is important.   If it
does not, then it is at worst harmless.  As was pointed out in
Toronto, we don't need to publish the thing, only to have it
handy for later consideration of whether it is needed and as a
ready defensive measure if someone claims that another URNbis
document is unacceptable because it somehow violates 3986.

I'll respond separately to Keith's and Leslie's later
"Preferences" notes.

   john