Subject: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Feb 2017 16:37:16 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-urnbis-rfc2141bis-urn-21: Abstain

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

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;-)

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 1 Mar 2017 07:16:12 +0000

Hello Stephen, 

Two comments: 

As regards this,

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

the National Library of Finland intends to revise its current URN resolver so that it supports r- and q-components. Funding for this work has been obtained from EU project EUDAT, which applies persistent identifiers to research data sets. The work will start as soon as RFC2141bis has become an Internet standard. 

As far as I know, there are no existing implementations of upcoming URN syntax features yet, since the URN user community has been patiently waiting for the final version of the URN syntax. Many of us are national libraries, so our time scale tends to be different from that of most other Internet organizations ;-). Once RFC2141bis has been published as an Internet standard, we still need to define the syntax for specifying resolution services and service parameters in the r-component. This should not take much time, and it can be done during the application development.   

Concerning this: 

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

URNBIS needed 6 years partly because there were many 3986-based URN issues the WG had to solve before sufficient consensus was found.  

Just to give one example, URI syntax says that: 

"The fragment identifier component of a URI allows indirect
   identification of a secondary resource by reference to a primary
   resource and additional identifying information."
 
However, f-component in the URN syntax has no role in identification, since fragment identifiers would have extended the scope of many existing standard identifier systems in an unacceptable manner. For instance, ISBNs identify books but not their component parts, so a URN:ISBN with an f-component still identifies a book as a whole, and the f-component indicates just a location within the book.   

The communities using URNs and other persistent identifiers (national libraries, national archives, universities, research institutions, scientific publishers etc.) need an updated URN syntax specification, not an improved version of URI syntax - which might of course be very useful for many other Web users out there. Be that as it may, I am glad that URI syntax revision is outside the scope of the URNBIS WG.      

All the best, 

Juha Hakala   

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: 1. maaliskuuta 2017 2:37
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-urnbis-rfc2141bis-
> [email-masked]; [email-masked]
> Subject: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-
> 21: (with COMMENT)
> 
> 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.)
> 
> 
> 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;-)
> 
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn