Uniform Resource Names (URNs)
draft-ietf-urnbis-rfc2141bis-urn-22

[Ballot comment]
= General =

I agree with Stephen that this spec seems unnecessarily long. There are a bunch of instances of repeated text in different sections that reference each other. I realize this doc was a negotiated outcome but if doing a streamlining pass is a possibility, it wouldn't hurt IMO.

= Section 2.3.1 =

Given that r-components are expected to be standardized elsewhere, I’m wondering if the expression of the normative requirements might be more prudent if it were phrased more along these lines:

---

OLD
Thus r-components SHOULD NOT be used for actual
  URNs until additional development and standardization work is
  complete, including specification of any necessary registration
  mechanisms.

NEW
Thus r-components SHOULD NOT be used for URNs before their semantics have been standardized.

---

Since the expectation is that the future standardization efforts will take place elsewhere, it doesn’t seem justified to try to constrain those efforts by normatively recommending registry mechanisms or imposing an undefined notion of what it means for future standards to be “complete.” Better to be clear that all this document is doing is specifying syntax and therefore cannot constrain how people decide to use r-components in the future. I also was not sure what an “actual” URN is.

= Section 4.4 =

"Further, all URN-aware applications MUST
  offer the option of displaying URNs in this canonical form to allow
  for direct transcription (for example by copy-and-paste techniques)."

I know this was in 2141, but it seems needlessly constraining on applications and I would be surprised if every application that is aware of URNs actually does this.

In general I think it would be preferable to avoid specifying normative requirements about what applications are to display, including the other requirements added to this section that were not in 2141.

= Section 8 =

Agree with Stephen's comment here.

= Appendix C =

"Truly experimental usages MAY, of course, employ
      the 'example' namespace [RFC6963]."

It seems inappropriate to have normative language in this appendix.

[Ballot comment]
I agree with Alissa's comment about the "r-component" section. It seems to me that defining the syntax without the semantics risks finding out later the syntax was wrong.

I agree with the general comments that this seems longer than it needs to be, and that we should remember that excess text has a cognitive cost. But it seems too late in the process to do much about that.

The review tracker indicates there has been no GENART or SECDIR reviews. That's unfortunate, but I guess not a show stopper.

[Ballot comment]
I agree with Stephen about the document length.  Although if the WG has spent 6 years on this already, I wouldn't want to see too many more cycles go into it.

[Ballot discuss]
What is the motivation behind specifying the r-component syntax at this point and then recommending against its use until further standardization is complete? Why not specify the syntax when those future standards get written? The current approach just seems like an invitation for people to start including r-components in URNs without independent implementations understanding their semantics.

[Ballot comment]
= General =

I agree with Stephen that this spec seems unnecessarily long. There are a bunch of instances of repeated text in different sections that reference each other. I realize this doc was a negotiated outcome but if doing a streamlining pass is a possibility, it wouldn't hurt IMO.

= Section 4.4 =

"Further, all URN-aware applications MUST
  offer the option of displaying URNs in this canonical form to allow
  for direct transcription (for example by copy-and-paste techniques)."

I know this was in 2141, but it seems needlessly constraining on applications and I would be surprised if every application that is aware of URNs actually does this.

In general I think it would be preferable to avoid specifying normative requirements about what applications are to display, including the other requirements added to this section that were not in 2141.

= Section 8 =

Agree with Stephen's comment here.

= Appendix C =

"Truly experimental usages MAY, of course, employ
      the 'example' namespace [RFC6963]."

It seems inappropriate to have normative language in this appendix.

[Ballot comment]

I am not convinced that doubling the amount of text vs. 2141
and 3406 here is really helpful. The draft also seems to
spend more time saying what it does not specify rather than
what it does. My not-that-well-informed guess is that this
product of stalwart effort does not improve the Internet,
despite the earnest extended multi-year efforts of the few
folks involved. I'd further bet that the world in general
would be fine if this did not become and RFC.  Normally,
I'd just ballot no-objection and let that go, but given
that this has consumed cycles for 6 years that could
perhaps have been more usefully engaged in dealing with
3986 issues, I think abstaining is a better position to
take on the off-chance that that sends some tiny form of
signal. (Apologies to those who engaged in this work, I
don't mean any disrespect, but I don't think the result
here is really worth the effort expended.)

- What deployed code supports the ?+ or ?= constructs?  If
some arguably "important" code does, I'd change my abstain
to a no-objection, as then there'd be an at least modest
new feature to justify the new RFC.

- Section 8 should I think recognise the dangers inherent
in long-term stable identifiers helping with
(re-)identification of people and/or network entities.
While that is not the "fault" of URNs, I'd say it is worth
warning folks who may just possibly think twice before
creating new URNs with those failings. (Though I recognise
that that may call for a reference to RFC6919;-)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-urnbis-rfc2141bis-urn-20.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Uniform Resource Identifier (URI) Schemes registry located at:

https://www.iana.org/assignments/uri-schemes/

the entry for the URI Scheme "urn" will have its reference changed from RFC 2141 to [RFC-to-be].

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Second, in Uniform Resource Names (URN) Namespaces registry located at:

http://www.iana.org/assignments/urn-namespaces

the reference to RFC 2141 at the top of the Formal URN Namespaces registry will be changed to [RFC-to-be].

Third, in the Uniform Resource Names (URN) Namespaces registry located at:

http://www.iana.org/assignments/urn-namespaces

the reference to RFC 2141 at the top of the Informal URN Namespaces registry will be changed to [RFC-to-be].

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Barry Leiba" , barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, alexey.melnikov@isode.com, urn@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Uniform Resource Names (URNs)) to Proposed Standard


The IESG has received a request from the Uniform Resource Names, Revised
WG (urnbis) to consider the following document:
- 'Uniform Resource Names (URNs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-02-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  A Uniform Resource Name (URN) is a Uniform Resource Identifier (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 the
  Internet Assigned Numbers Authority (IANA).  This document obsoletes
  both RFC 2141 and RFC 3406.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ballot/


No IPR declarations have been submitted directly on this I-D.

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.