[urn] Alissa Cooper's No Objection on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 02 March 2017 15:30 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148846862902.19483.15030465452736704538.idtracker@ietfa.amsl.com>
Date: Thu, 02 Mar 2017 07:30:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/tqNyFJuiomMWoZ-c4RKdi0zzWQI>
Cc: urn@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org
Subject: [urn] Alissa Cooper's No Objection on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-urnbis-rfc2141bis-urn-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/



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

[urn] Alissa Cooper's No Objection on draft-ietf-… Alissa Cooper