[urn] Tuning the "URNs are not URIs" spec

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

Hi.

After several discussions in the last two weeks, including two
very significant (to me at least) offline and face to face ones,
it seems to me that the explanation in
draft-ietf-urnbis-urns-are-not-uris-00 may be missing the point
or be irrelevant to some people.  Consequently, I propose to add
the following text to the I-D.  It was written on the assumption
that it would be an appendix but that is not a firm decision or
anything we need to decide now.  If we do want to keep it for
the long term (as distinct from helping with discussion in the
interim), perhaps we should think about creating two subsections
of Section 2, one more or less the present Section 2 and the
other a variation on the text below.

In any event, comments welcome on the text below.  Unless the
general sense of the WG is that it sets us backwards, I'd
generate and post a new draft that incorporates it (and any
agreeable modifications) sometime next week.  Again, having the
text at this point is not a commitment for it to be in the final
document.  The question, IMO, is whether it will help to move
the discussions forward and thereby contribute to getting the
WG's work unstuck.

    john

   ----- Proposed text -----------

Appendix A.  A More Pragmatic Perspective

   Section 2 provides an explanation of the reasons for this
   change.  That explanation is not without controversy,
   especially from those who make different assumptions about
   the future, or even interpretations of the present, than
   many members of the community (and especially members of
   the communities describe in that section).  Some of those
   who do not accept the explanation above simply do not
   recognize the distinctions on which it, and URNs more
   generally, are based, including the name-locator
   distinction.  In some cases, opposition to that explanation
   is quite pronounced, involving fundamental differences in
   philosophy that move beyond mere differences of opinion.

   Like most controversies in which one group does not accept
   the definitions, facts, or logic of another, the
   differences are unlikely to be resolved by further
   discussion, no matter how sensible and patient.  The
   material in this appendix is provided for the benefit of
   those who cannot accept Section 2 or consider the
   discussion there to be meaningless.

   Independent of the details of the discussion above, in the
   case of URNs, the IETF is faced with a pair of problems
   that are ultimately faced sooner or later by all voluntary
   standards bodies: nothing except quality and broad
   community consensus prevents a standard from being ignored
   in the marketplace and nothing prevents another body from
   creating a competing standard.  The effort required to
   create a competing standard can be increased and its
   potential for confusion can be reduced somewhat by various
   measures -- measures the IETF has rarely tried to actually
   use -- but those measures are rarely effective when the
   other body is convinced that they have legitimate and
   significant needs that differ from the original atandard.
   Because of those problems, the key question for the URN
   effort is ultimately not whether a clear enough distinction
   exists between names and locator or location-based
   information, nor whether "persistent" can be defined
   clearly enough, nor even whether the communities and
   requirements described in Section 2 are valid or will be
   judged valid in retrospect in a few decades or centuries.
   Instead, the question is whether the IETF is willing to
   evolve and adapt the URN definition to accommodate those
   perceived needs or whether if prefers to have that work
   done elsewhere, either by adoption in the broader
   community and marketplace of a different approach or,
   potentially, even a competing URN standard.  If, in the
   long run, those other communities and perspectives turn
   out to be wrong, the additional features will atrophy.  But
   that would be true whether they are specified and
   standardized in the IETF or elsewhere. 

 --- end proposed text -----------