1. Summary
This document defines "Uniform Resource Name", a URI that is assigned
under the "urn" URI scheme and a particular URN namespace, with the
intent that the URN will be a persistent, location-independent resource
identifier. 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 IANA. This document obsoletes RFCs 2141 and 3406.
The document is defining a standard, and is therefore submitted to the
Standards Track as a Proposed Standard.
Barry Leiba is the document shepherd; Alexey Melnikov is the responsible
Area Director.
2. Review and Consensus
The life of this document and the URNbis working group that produced it
has been long and troubled. Over the six years since the work started,
the document has been reviewed by a fair number of people, but they have
come and gone over those years. What remains is a stalwart, relatively
small group -- on the order of ten participants -- who have stuck it
through and continue to comment. That stalwart group comprises
essentially the entire community within the IETF that cares how this
comes out, which is a good sign. A few people who were active
participants some time ago have gone silent over the last year or so,
and they could resurface during IETF last call.
Yet that stalwart group disagrees on many things, which fact has
resulted in a six-year process for something that we expected to take
more like two. It doesn't make much sense to try to list specific
topics for which there was disagreement. What makes more sense is to
note that most of the active participants were on a conference call at
the end of June 2016, and that that call resulted in discussion of and
plans for resolution of all the significant disagreements that remained.
It took the authors a number of months to be able to allocate the time
to go through and make the agreed-upon changes, but that call showed
that the working group really was able to work together, compromise when
necessary, and come up with something everyone could live with, even if
it wasn't their preferred solution.
The resulting document is a solid piece of work that does have rough
consensus of the working group and accomplishes what the working group
set out to do.
One point that does merit pointing out is the relationship of this
document to RFC 3986 (which defines URIs, and which is a key related
document). There were discussions of deviating from 3986 or not, and
how far, if so. There were discussions of what the concepts of URI
fragments and query strings can mean with respect to URNs, whether to
allow them, and how to handle them, if so. There were discussions of
what to say about whether and when URNs might be resolvable, and what
that would mean. In the end, while there remains some level of
disagreement about some of that, the current document represents a
consensus view on the resolution of those discussions.
3. Intellectual Property
The authors are in full conformance with BCPs 78 and 79. There are no
IPR disclosures on this document.
4. Other Points
We were very recently able to get the necessary BCP 78 approval from the
author of RFC 2141 order to remove the pre-5378 disclaimer that appeared
up through version -19.
There are intentional informational references to RFCs 1738 and 1808,
which are obsolete (they are predecessors to RFC 3986, and are cited
as such).
The document significantly changes the IANA registration procedure for
new URN namespaces (which has so far been specified as IETF Consensus
for formal namespaces, and that has proved to be unnecessarily strict
and cumbersome, and has caused squatting problems). The working group
looked at recent registrations to evaluate the proposed process. The
process will require the appointment of designated experts.
Registration requests come in fairly often and review is sufficiently
important that a review team with a coherent team process is
recommended.
There are no downward normative references.