Re: [urn] r-components and resolverID

["Hakala, Juha E" <[e-mail]>]

John; all, 

some additional comments inline. 

> -----Original Message-----
> From: urn [mailto:[e-mail]] On Behalf Of John C Klensin
> Sent: 12. huhtikuuta 2016 19:02
> To: Sean Leonard <[e-mail]>; [e-mail]
> 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.
> 
> --On Tuesday, April 12, 2016 06:18 -0700 Sean Leonard
> <[e-mail]> 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.  

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

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. 

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

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

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

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   

> 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
> 
> 
> 
> 
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn