Subject: Re: [urn] r-components and resolverID

From: John C Klensin <[email-masked]>
Date: Tue, 12 Apr 2016 12:02:20 -0400

Sean,

Your quick response is much appreciated.  Several comments
inline below but I want to assure you that your comments prior
to today have been _very_ carefully considered.

--On Tuesday, April 12, 2016 06:18 -0700 Sean Leonard
<[email-masked]> wrote:

> Hi John,
> 
> I have feedback and comments. However, due to IETF 95
> happening, I am sure that I, and other participants, have been
> very busy with other things. Given the speed at which this
> working group has progressed, another week or two would not be
> unreasonable.

Normally yes (and IETF 95 is precisely the reason my note did
not show up a week or two ago) but we do have another problem.
ISO TC 46 ("Information and documentation") will hold their
annual plenary meeting the second week in May.  As the IETF
Liaison to them, I owe them a report by a week from today.   In
each of the last several years, we've told them that we were
nearly finished with a new URN standard, updated to accommodate
various of the needs of their communities, to be completed well
before their next meeting.   To put it mildly, that tale is
getting a little old.  Absent other instructions from the WG or
IAB, I need to go tell it again, try to keep a straight face,
and probably end up having to explain why they should take us
seriously this time.  I have no idea how to do the latter
convincingly, especially if we are back to discussing
fundamentals of what URNs are for and about (see below).

TC 46 is important because their national member participants
tend to be the representatives of institutions that know a great
deal about persistent identifiers, including a great many
archival/ repository libraries and museums.  TC 46 is directly
responsible for a lot of the identifiers we are very concerned
about and have been using as examples from almost the time we
started talking about URNs, including ISBNs and ISSNs (as well
as ISO 3166 country codes and having joint responsibility for
the other codes that are the underpinnings of our language
identifiers, etc.).  During the time that we've been dithering
about URNs (or, if you prefer, carefully considering the options
and working toward the best standard possible), they created and
adopted an International Standard for DOIs.  I don't personally
believe we could have stopped that, or that we should have tried
to do so even if we could, but the door is closing rapidly on
any possibility of what we would call an applicability statement
with clear advice as to when to use DOIs and when to use URNs.

If we lose the TC 46 community to the point that they start
seriously considering the development of URNs, or a URN-type
identifier, on their own, I think URNs are basically over.  A
year ago, I would have said "except for IETF documents" but the
application of DOIs to RFCs can be used to make a case that URNs
are a lot less important to IETF documents than we might have
claimed a couple of years ago.  I'm not suggesting that TC 46 is
that important by itself (although, in a lot of contexts, it
probably is) but remember that DOIs are being aggressively
promoted for many applications, much of the Web community thinks
that URNs are useless at best and, at worst, distracting
syntactic sugar sprinkled on top of distinct URI schemes for
many cases. The Semantic Web portion of that community thinks
they are a useless distraction (or worse), and so on.   There
are a _lot_ of persistent, location-independent, identifiers for
digital (and equivalent) objects out there.  URNs could have
been the unifying framework, but that window is closing (perhaps
has already closed) and the sphere of applicability narrows with
each major group that wanders off in some other direction or
decides to adopt a standard of their own.

If we can't get this done, and done soon, we should probably
just stop -- I can't speak for others in the WG, although the
apparently dropping level of engagement may be a clue, but I
don't want to be putting energy into making epicycles work a
little bit better in a post-Kepler era.

> Thank you for writing out some of the possible paths forward.

I think we are a little past that.  See below.

> (Also I would like to point out, that just because I have been
> one of the few persistent voices in this discussion, should
> not discount my contributions. Quite the opposite, in fact.
> Especially since I am an implementer. Others are always
> welcome to express their own opinions. I did ask that we meet
> at IETF 95 so that these issues could be discussed in person
> with others in the room or in the virtual meeting, but that
> did not happen.)

Take that up with the Co-chairs.  I personally would not object
to a virtual meeting if there were evidence that the right mix
of people would attend and that it would have a useful agenda.
I would have objected to a f2f meeting in Buenos Aires because
the right mix of people definitely would _not_ have been there
-- no Peter, no me, no one from the library or museum
communities, etc.

However, after a great deal of thought about how to accommodate
your ideas,  I think we are facing a more fundamental problem
that goes directly to the importance of your views as an
implementer.   There is a conceptual model of what URNs are
about, a model whose first versions were outlined in RFCs 1737,
2141, and 2276.  It is no secret that I'm not a fan of a lot of
the details of 1737 and that I believe that some of the efforts
to follow up 2276 represent failed experiments.  At the same
time, there is a conceptual model in those documents, particular
2141 and the definition/registration mechanisms of 3406, and
there are a lot of namespaces (registered and otherwise) and
many millions of URNs that are consistent with that model.  

With the understanding that this is just my personal opinion,
when we start decoupling resolution arrangements from the
NID/Namespace (including indirection through a resolver-finding
service as something anticipated since the beginning) and move
toward selection of resolvers in the URN, perhaps using those
selections as a means of determining what information is wanted,
we move sufficiently outside the historical URN scheme model to
really be talking about something else.  I actually find that
idea quite interesting.  It may be a sort of midway point
between "locator" and "name", countering the historical claim
that the two represent a dichotomy with nothing in between.  But
it isn't, again IMO, a historical URN scheme type of
arrangement,  While I've very clearly heard "I'm an implementer
and I think this is a useful approach" (it is why I tried to
incorporate an anchor for your syntax into 2141bis), I haven't
heard those who represent users of URNs say "we see a need for
URNs to go in that direction".    My request for additional
voices and arguments was, and is, a desire to see if the user
demand is out there.   At least in its absence, I am
increasingly convinced that you should be looking at a separate,
name-like, URI scheme that accommodates those ideas rather than
trying to pull the URN scheme in that direction.  The fear that
we will lose URNs entirely if we try to pin down the details of
your model and then figure out if the result is still compatible
with historical URNs is only part of that concern; most of the
concern is about where the conceptual boundaries lie and what
the current and potential user communities think they need.

Again, just my opinion -- I'm still waiting for input from the
WG and/or additional instructions from the co-chairs.   Since
-16 is a step away from your ideas (while -15 was a step toward
them although not as big a step as you wanted), I'm reluctant to
post it until I see that input.  

     john

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 13 Apr 2016 06:10:58 +0000

John; all, 

some additional comments inline. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: 12. huhtikuuta 2016 19:02
> To: Sean Leonard <[email-masked]>; [email-masked]
> Subject: Re: [urn] r-components and resolverID
> 
> Sean,
> 
> Your quick response is much appreciated.  Several comments inline below
> but I want to assure you that your comments prior to today have been _very_
> carefully considered.
> 
> > I have feedback and comments. However, due to IETF 95 happening, I am
> > sure that I, and other participants, have been very busy with other
> > things. Given the speed at which this working group has progressed,
> > another week or two would not be unreasonable.
> 
> Normally yes (and IETF 95 is precisely the reason my note did not show up a
> week or two ago) but we do have another problem.
> ISO TC 46 ("Information and documentation") will hold their annual plenary
> meeting the second week in May.  As the IETF
> each of the last several years, we've told them that we were nearly finished
> with a new URN standard, updated to accommodate various of the needs of
> their communities, to be completed well
> getting a little old.  

TC 46 attendees do understand that sometimes it is difficult to complete standards. However, ISO directives do specify strict time limits, so things cannot go on forever. Also there is a limit on how many drafts can be written. URNBIS is by now well past anything that would be acceptable or even possible in ISO standardization process.    

Absent other instructions from the WG or IAB, I need to
> go tell it again, try to keep a straight face, and probably end up having to
> explain why they should take us seriously this time.  I have no idea how to do
> the latter convincingly, especially if we are back to discussing fundamentals
> of what URNs are for and about (see below).

Since many of the attendees will represent organizations or interest groups which use persistent identifiers (national libraries, national archives, scientific publishers) possible failure to revise URN standards is a concern especially to those who are using URNs, but also to the PID community as a whole. There is a shared interest to make PIDs smarter, and URN could provide an example of how that can be done.  

> 
> TC 46 is important because their national member participants tend to be
> the representatives of institutions that know a great deal about persistent
> identifiers, including a great many archival/ repository libraries and
> museums.  TC 46 is directly responsible for a lot of the identifiers we are
> very concerned about and have been using as examples from almost the
> time we started talking about URNs, including ISBNs and ISSNs (as well as
> ISO 3166 country codes and having joint responsibility for the other codes
> that are the underpinnings of our language identifiers, etc.).  During the time
> that we've been dithering about URNs (or, if you prefer, carefully
> considering the options and working toward the best standard possible),
> they created and adopted an International Standard for DOIs.  I don't
> personally believe we could have stopped that, or that we should have tried
> to do so even if we could, but the door is closing rapidly on any possibility of
> what we would call an applicability statement with clear advice as to when
> to use DOIs and when to use URNs.

DOI standardization in ISO predated the URNBIS work. DOI is based on Handle system (see RFC 3650), so most of the technical aspects in the standardization process were fixed. We did spend a lot of time discussing potential overlap between DOIs and other ISO standard identifiers. Since DOI can in theory be used to identify any object, it may replace for instance ISBN in the identification of books. The standard contains some prose to prevent this kind of misuse of DOIs. In practice, using DOIs for identification of "wrong" objects has not been an issue.    

> If we lose the TC 46 community to the point that they start seriously
> considering the development of URNs, or a URN-type identifier, on their
> own, I think URNs are basically over.  A year ago, I would have said "except
> for IETF documents" but the application of DOIs to RFCs can be used to
> make a case that URNs are a lot less important to IETF documents than we
> might have claimed a couple of years ago.  I'm not suggesting that TC 46 is
> that important by itself (although, in a lot of contexts, it probably is) but
> remember that DOIs are being aggressively promoted for many applications,
> much of the Web community thinks that URNs are useless at best and, at
> worst, distracting syntactic sugar sprinkled on top of distinct URI schemes
> for many cases. The Semantic Web portion of that community thinks
> are a _lot_ of persistent, location-independent, identifiers for digital (and
> equivalent) objects out there.  URNs could have been the unifying
> framework, but that window is closing (perhaps has already closed) and the
> sphere of applicability narrows with each major group that wanders off in
> some other direction or decides to adopt a standard of their own.

IETF has already "lost" Handles to ITU. ARK has not made it beyond Internet draft, and right now it does not seem likely that it will be published even as an informational RFC. And revising URN has definitely been far more difficult than I ever thought it would be. 

Persistent identifiers are used a lot. For instance, there were about five billion DOI resolutions in 2015. In the same time we know - based on e.g. research by Herbert Van de Sompel and others, see http://dx.doi.org/10.1371/journal.pone.0115253  - that URLs are not nearly as cool as some people think they are. There is definitely a need for persistent identifiers which are better managed and offer richer functionality than plain vanilla URLs. Whether IETF wants to have any role in this in the future must be considered carefully. It seems to me that at least some members in URNBIS tend to forget the strategic importance for IETF of being involved with PID standardization. URNBIS has spent a lot of time discussing technical details which could have been ignored - and certainly similar things have been ignored in standardization of other PIDs. 
> 
> If we can't get this done, and done soon, we should probably just stop -- I
> can't speak for others in the WG, although the apparently dropping level of
> engagement may be a clue, but I don't want to be putting energy into
> making epicycles work a little bit better in a post-Kepler era.

If IETF drops URNs, that should be done gracefully. TC 46/SC 9, which deals with identifiers, can complete the URN syntax revision, but this should be agreed between IETF and ISO. Having said this, I still hope that URNBIS finishes the documents. Then they could be standardized via fast track process in ISO. 

Technical issues URNBIS has been battling with are unlikely to become a problem in a more practically oriented TC 46. DOI standard and its underlying Handle specification are - from URI syntax point of view - in some ways problematic documents, but this has not prevented Handle and DOI from becoming very popular and useful PID systems. 

> > (Also I would like to point out, that just because I have been one of
> > the few persistent voices in this discussion, should not discount my
> > contributions. Quite the opposite, in fact.
> > Especially since I am an implementer. Others are always welcome to
> > express their own opinions. I did ask that we meet at IETF 95 so that
> > these issues could be discussed in person with others in the room or
> > in the virtual meeting, but that did not happen.)
> 
> Take that up with the Co-chairs.  I personally would not object to a virtual
> meeting if there were evidence that the right mix of people would attend
> and that it would have a useful agenda.
> I would have objected to a f2f meeting in Buenos Aires because the right
> mix of people definitely would _not_ have been there
> -- no Peter, no me, no one from the library or museum communities, etc.

It is a pity that most URN users have been just lurking on this list. Some of my colleagues who work with URN assignment in practice got frustrated long time ago due to the theoretical nature of much of the discussion. Few contributions seemed to relate directly or even indirectly to what they were doing with URNs and what they wanted to do with them in the future.   

> However, after a great deal of thought about how to accommodate your
> ideas,  I think we are facing a more fundamental problem that goes directly
> to the importance of your views as an
> about, a model whose first versions were outlined in RFCs 1737, 2141, and
> 2276.  It is no secret that I'm not a fan of a lot of the details of 1737 and
> that I believe that some of the efforts to follow up 2276 represent failed
> experiments.  At the same time, there is a conceptual model in those
> documents, particular
> 2141 and the definition/registration mechanisms of 3406, and there are a
> lot of namespaces (registered and otherwise) and many millions of URNs
> that are consistent with that model.
> 
> With the understanding that this is just my personal opinion, when we start
> decoupling resolution arrangements from the NID/Namespace (including
> indirection through a resolver-finding service as something anticipated since
> the beginning) and move toward selection of resolvers in the URN, perhaps
> using those selections as a means of determining what information is
> wanted, we move sufficiently outside the historical URN scheme model to
> really be talking about something else.  I actually find that idea quite
> interesting.  

Me too. The model RFC 2276 is too narrow, and does not take into account that the same object may be available from different services on different terms. 

So this section from RFC 2276: 

"we assume that the publisher of a resource can choose resolver services,
   independently of choices made by others.  At any given time, the
   owner of a namespace may choose a particular URN resolver service for
   that delegated namespace."

should be expanded in such a way that at least in some (large, standard based) namespaces it has to be possible to choose resolution service in the item level. For instance, there can be three items (copies) of an electronic PhD dissertation available in the Web: one in the national library's legal deposit system, another in the digital asset management system of the university (available for free) and one in publisher's web site (available for fee). All these copies of the book have the same ISBN, so the first part of the resolution process for the user is to decide which copy / target system is the preferred one. There are various ways to implement this; for instance, if the identified resource is available on multiple target systems, the resolver may be able to check from an external service which copy / copies the user is entitled to access and use. Libraries have already implemented this kind of services. So whether we must change the URN syntax to enable this kind of enrichment of the resolution process depends on the technical infrastructure available.      

It may be a sort of midway point between "locator" and
> "name", countering the historical claim that the two represent a dichotomy
> with nothing in between.  But it isn't, again IMO, a historical URN scheme
> type of arrangement,  While I've very clearly heard "I'm an implementer and
> I think this is a useful approach" (it is why I tried to incorporate an anchor for
> your syntax into 2141bis), I haven't heard those who represent users of
> URNs say "we see a need for
> increasingly convinced that you should be looking at a separate, name-like,
> URI scheme that accommodates those ideas rather than trying to pull the
> URN scheme in that direction.  The fear that we will lose URNs entirely if
> we try to pin down the details of your model and then figure out if the result
> is still compatible with historical URNs is only part of that concern; most of
> the concern is about where the conceptual boundaries lie and what the
> current and potential user communities think they need.

Putting my TC 46 hat on, my recommendation is to complete the URN syntax standardization as fast as possible, and not to try to add any major features into it anymore. PIDs and PID resolvers need to become smarter in synch with the development of the underlying technical infrastructure such as applications used by libraries, archives and museums. There is no way to create now the final version of URN syntax which will be sufficient for a very long time. Instead, IETF (or whichever organization is responsible of the system) needs to be prepared to revise URN specifications often enough, and hopefully next time around the process will not last for years and years.

All the best, 

Juha   

> -16 is a step away from your ideas (while -15 was a step toward them
> although not as big a step as you wanted), I'm reluctant to post it until I see
> that input.
> 
>      john
> 
> 
> 
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Apr 2016 09:49:19 -0600

> some additional comments inline.

Juha, thanks for your input. I agree on all points. Let's finish this 
work soon (which implies not expanding the scope at this time).

Peter

> should be expanded in such a way that at least in some (large, standard based) namespaces it has to be possible to choose resolution service in the item level. For instance, there can be three items (copies) of an electronic PhD dissertation available in the Web: one in the national library's legal deposit system, another in the digital asset management system of the university (available for free) and one in publisher's web site (available for fee). All these copies of the book have the same ISBN, so the first part of the resolution process for the user is to decide which copy / target system is the preferred one. There are various ways to implement this; for instance, if the identified resource is available on multiple target systems, the resolver may be able to check from an external service which copy / copies the user is entitled to access and use. Libraries have already implemented this kind of services. So whether we must change the URN syntax to enable this kind of 
 enrichmen
t
>    of the resolution process depends on the technical infrastructure available.
>