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

= 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.

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.

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.