Subject: [urn] Tuning the "URNs are not URIs" spec

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jun 2014 04:25:42 -0400

Hi.

After several discussions in the last two weeks, including two
very significant (to me at least) offline and face to face ones,
it seems to me that the explanation in
draft-ietf-urnbis-urns-are-not-uris-00 may be missing the point
or be irrelevant to some people.  Consequently, I propose to add
the following text to the I-D.  It was written on the assumption
that it would be an appendix but that is not a firm decision or
anything we need to decide now.  If we do want to keep it for
the long term (as distinct from helping with discussion in the
interim), perhaps we should think about creating two subsections
of Section 2, one more or less the present Section 2 and the
other a variation on the text below.

In any event, comments welcome on the text below.  Unless the
general sense of the WG is that it sets us backwards, I'd
generate and post a new draft that incorporates it (and any
agreeable modifications) sometime next week.  Again, having the
text at this point is not a commitment for it to be in the final
document.  The question, IMO, is whether it will help to move
the discussions forward and thereby contribute to getting the
WG's work unstuck.

    john

   ----- Proposed text -----------

Appendix A.  A More Pragmatic Perspective

   Section 2 provides an explanation of the reasons for this
   change.  That explanation is not without controversy,
   especially from those who make different assumptions about
   the future, or even interpretations of the present, than
   many members of the community (and especially members of
   the communities describe in that section).  Some of those
   who do not accept the explanation above simply do not
   recognize the distinctions on which it, and URNs more
   generally, are based, including the name-locator
   distinction.  In some cases, opposition to that explanation
   is quite pronounced, involving fundamental differences in
   philosophy that move beyond mere differences of opinion.

   Like most controversies in which one group does not accept
   the definitions, facts, or logic of another, the
   differences are unlikely to be resolved by further
   discussion, no matter how sensible and patient.  The
   material in this appendix is provided for the benefit of
   those who cannot accept Section 2 or consider the
   discussion there to be meaningless.

   Independent of the details of the discussion above, in the
   case of URNs, the IETF is faced with a pair of problems
   that are ultimately faced sooner or later by all voluntary
   standards bodies: nothing except quality and broad
   community consensus prevents a standard from being ignored
   in the marketplace and nothing prevents another body from
   creating a competing standard.  The effort required to
   create a competing standard can be increased and its
   potential for confusion can be reduced somewhat by various
   measures -- measures the IETF has rarely tried to actually
   use -- but those measures are rarely effective when the
   other body is convinced that they have legitimate and
   significant needs that differ from the original atandard.
   Because of those problems, the key question for the URN
   effort is ultimately not whether a clear enough distinction
   exists between names and locator or location-based
   information, nor whether "persistent" can be defined
   clearly enough, nor even whether the communities and
   requirements described in Section 2 are valid or will be
   judged valid in retrospect in a few decades or centuries.
   Instead, the question is whether the IETF is willing to
   evolve and adapt the URN definition to accommodate those
   perceived needs or whether if prefers to have that work
   done elsewhere, either by adoption in the broader
   community and marketplace of a different approach or,
   potentially, even a competing URN standard.  If, in the
   long run, those other communities and perspectives turn
   out to be wrong, the additional features will atrophy.  But
   that would be true whether they are specified and
   standardized in the IETF or elsewhere. 

 --- end proposed text -----------

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 17 Jun 2014 18:16:36 +0900

Hello John, others,

Your text proposal below is helpful because it shows how you frame the 
current discussion in terms of standard politics and procedures.

First, you mention "several discussions". These discussions may have 
lead you to certain conclusions, but it doesn't mean that WG members can 
make the same (or maybe other) conclusions without getting more 
information on these discussions, either from you or from the other 
people involved (or preferably from both).

I have no idea about the content of these discussions, but just for 
devil's advocate, there would be a huge difference between e.g. some of 
these discussions including very clear indications (even threats) of 
"having that work done elsewhere" and e.g. discussants showing little or 
no understanding for the (real or perceived) needs of (some parts of) 
the library community. Maybe there was both, or there was something else 
althogether.

So I would strongly urge you and others who have been involved in these 
discussions to inform the WG and therefore the public via this list.

Second, and more important, is that your document starts at the wrong 
end. Section 2 may be a good start for a requirements document. And 
based on that, it may be possible to work out how to address the various 
issues brought up. After discussion of each of the requirements and 
possible solutions addressing these, we would end up with a spec that 
may or may not have some discrepancies with RFC 3986. It is at this 
point, and only at this point, that we can with good faith decide to put 
something like the current Section 3 into the spec, and to label the 
document as "updates 3986". Cutting ties before we know we need to cut 
them is hopelessly premature.

I don't currently have the time to go through all nine items in Section 
2 (*). But in order to show that what I said in the previous paragraph 
is important, I'm going to pick out one item and explain my concerns in 
more detail:

    7.  Persistent identification must be available for resources which
        are available only in databases and other environments that are
        often identified today as "deep web".  URIs for these resources
        tend to be very complicated and it will be difficult to keep them
        alive even with the help of DNS redirection when e.g.  the
        underlying database management system changes.

Reading this, I don't see any point I would have to disagree with. But 
there is also nothing I can see or even guess that would suggest that 
persistent identification (meaning URNs, yes?) and URIs need to be 
separated. It is already possible with current syntax to define URNs for 
resources in the "deep web". Keeping the correspondence between such 
URNs and their referent will be difficult when the underlying database 
management system changes. As far as I can see, that's not URI's fault 
and not URN's fault, and isn't affected, positively or negatively, by 
separating URNs from URIs. Similar for length issues. It's possible to 
define short URNs or short URIs if that's what is needed. Both for URNs 
and for URIs, there are ample examples. Again, length issues are not 
affected, positively or negatively, by separating URNs from URIs.

So at the minimum, items such as item 7 need a lot more work to make the 
connection to Section 3 way clearer. Or they should just be removed as 
non-sequiturs, leaving only those items (if any) that actually support a 
conclusion such as that in Section 3.

So in summary, I'd strongly suggest to invest *way more* work into the 
technical aspects of this document. The IETF has a very strong and 
healthy tradition of putting technical arguments first. It is my strong 
belief that if the technical arguments are actually there and are 
presented well enough, then political/procedural text such as the 
appendix below won't be necessary. On the other hand, if the technical 
arguments can't be found, then again the appendix below (and the whole 
document) will become irrelevant.

Regards,    Martin.

(*) I note in passing that the paragraphs between item 8 and 9, and 
those after item nine, should be formatted to be part of the preceding 
item).

On 2014/06/14 17:25, John C Klensin wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 17 Jun 2014 16:15:00 -0400

> From: John C Klensin <[email-masked]>

>    discussion, no matter how sensible and patient.

I'd phrase it "... in which EACH group does not accept ... of THE
OTHER".

>    potentially, even a competing URN standard.

As far as I can tell, the key question is "Is the syntax of RFC 2141
("URN syntax") inadequate for the needs of important groups of users?"
If the syntax is adequate, then various groups of users can define
namespaces that have the properties that they desire without causing
any upset in running code; at most, revisions would be needed to RFC
3406 ("URN namespace definition mechanisms").  (Unlike IPv4 addresses,
we aren't in danger of running out of namespace identifiers.)

(And for example, this flexibility allows multiple sets of identifiers
which handle name/locator differences in distinctly different ways.)

What seems to be constantly hinted at in this discussion -- but never
explicitly stated -- is that important groups of users have needs that
CANNOT be satisfied within the syntax of RFC 2141.  Not just that the
particular definitions of "fragment" and "query" in RFC 3986 are
inadequate for their needs, but that those needs cannot be satisfied
by *any alternative means* that can be represented within the syntax
of RFC 2141.

If that actually is so, it is a fairly concrete fact, it shouldn't be
very difficult to make the case in a convincing way.  And once the
case is made, it would be a sound reason to move ahead with
significant changes to the status quo.

One objection I can see to RFC 2141 is how restrictive it is:  The
namespace-specific string can contain only letters (two cases),
digits, and 15 of the 32 ASCII special characters.  (That's not
counting %, since it has a special purpose.)  I can see how a group
may want to have much more syntactic flexibility in designing an
identifier, and they wouldn't enjoy %-encoding a large fraction of the
characters in their identifiers.

OTOH, there's no reason that a user group would have to *see* what
their URNs look like very often.  Most user interfaces that would
refer to sophisticated identifiers don't have to reveal the URNs that
are used one the wire, any more than that we have to see the bits that
encode the characters of our e-mails.

For instance, there's no reason that DOIs can't be encoded much the
same way that EIDRs are encoded (draft-pal-eidr-urn-03):

    The DOI "10.1051/0004-6361:20054201"
    becomes the URN "urn:doi:10.1051:0004-6361%3a20054201".

(Any sequence of Unicode characters can be represented as a sequence
of %-escapes per RFC 2141 section 2.2.)

The great benefit of this approach is that generic operations on these
URNs can be done by the great bulk of currently running code.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Wed, 18 Jun 2014 10:34:31 +0300

Hello,

> ("URN syntax") inadequate for the needs of important groups of users?"
Urnbis charter requires (among other things) the WG to make

> an update of the formal syntax specification in the light of the
> URI Standard (STD 66, RFC 3986) using the ABNF from STD 68
> (RFC 5234)

In practice, two major changes are needed: revised URN syntax should 
allow the use of fragment and query.

The use of URI fragment to indicate locations within identified 
resources enables creation of URN-based citations instead of URL-based 
ones. But in order to avoid breaking the assignment rules of traditional 
standard identifiers, RFC2141bis must make it clear that the fragment is 
not part of the namespace specific string (that is, from URN point of 
view, it does not identify anything).

There is definitely also a need to use URI query for passing resolution 
related parameters to URN resolvers. URN resolvers currently in use are 
dumb; of all the resolution services specified in RFC 2483 they usually 
support by default only URN - URL mapping (to a single URL only). This 
is insufficient, since users may not want the document itself. Instead 
they may be interested in descriptive metadata about the resource, or 
other versions of the resource (work), etc.

DDDS  (Dynamic Delegation Discovery System) has been available since 
2002 as a means for passing service related information to resolvers, 
but it has not become popular. URI query provides a more lightweight and 
technically sufficient means for making URN resolvers smarter.
> we aren't in danger of running out of namespace identifiers.)
Services available in namespaces depend to large extent on applications 
used to manage the identified resources. That is, resolution services 
supported by a namespace will change over time.

For instance, with their current systems (such as integrated library 
systems and open repositories) libraries could in principle support all 
the URN resolution services specified in RFC 2483. In fact, there is 
already a problem since metadata about resource can be supplied in many 
metadata formats, and RFC 2483 does not allow the libraries to specify 
the format (it is supposed to be URC or Uniform Resource 
Characteristics, which does not exist).

In the future, when e.g. national libraries will establish digital 
preservation systems, a lot of new services will be available. For 
instance, a user can check if there are earlier / later versions of the 
identified resource in the digital archive. He will be able to compare 
the intellectual content of successive versions of the work, which may 
differ due to migrations needed to maintain the usability, and check 
which applications will be needed to render the preferred version readable.

> CANNOT be satisfied within the syntax of RFC 2141.

I have tried to make it clear that for instance library community needs 
additional functionality which can be provided by query and fragment.

> Not just that the
I can't see an acceptable alternative for the usage of fragments. 
Everyone must be able to make citations and references, but identifier 
assignment - when done properly - is a managed process.

DDDS could be used instead of query, but slow / non-existent adoption of 
the former during the last decade makes it clear to at least me that an 
alternative method is needed.

> significant changes to the status quo.

The problem is that what looks convincing to e.g. library community - 
and we are not the only significant group out here which is using 
persistent identifiers - may not convince other groups which have 
different requirements and applications. If there is no need to preserve 
millions of documents for hundreds of years, even cool URIs may look 
like a sufficient solution.
> characters in their identifiers.
In practice, many communities which use URNs do not see this as a 
significant limitation. Standard identifiers often allow only a very 
limited set of characters. And even if UNICODE is allowed in principle 
(as in Handle system), it is not used in practice.

The problem some traditional identifier systems such as ISBN and ISSN 
are facing when they are applied to digital documents has to do with the 
syntax. For instance, ISBN has been extended once (from ISBN-10 to 
ISBN-13) to extend the scope of the system. And the next revision is 
already under way.
> encode the characters of our e-mails.

Correct. If resolution service / services exist, then making an ISBN 
actionable by turning it into URN can be an automated process. And this 
actionability is all the ISBN users want from URNs. URN implementation 
should not change the scope of the ISBN system in any way.
> URNs can be done by the great bulk of currently running code.

Technically, DOIs (or Handles or ARKs) can be expressed as URNs, and 
vice versa. But there is no added value whatsoever if the URN is 
resolved in the same way as the DOI.

There is often just one traditional identifier (such as ISBN), but it 
has to be made actionable in different ways. Let's assume that we have a 
doctoral dissertation published in PDF format with an ISBN. DOI using 
this ISBN as suffix may resolve to the publisher's repository, which is 
behind a pay wall. Same ISBN as Handle may provide a link to the 
DSpace-based open repository maintained by the author's alma mater where 
the thesis is available for free. And finally the national library may 
have a legal deposit copy of the book with URN:ISBN, available for free 
but only on dedicated workstations in legal deposit libraries (so a user 
not using one of these workstations will only get metadata about the book).

In theory, all this functionality could be provided by the publisher's 
DOI resolver. In practice, this is not likely to happen, for financial 
reasons that should be quite obvious. As an aside, PID communities are 
currently considering creation of multi-PID resolvers (via e.g. adding 
URN resolution functionality to the Handle software). This is necessary 
since there are (open) repositories which contain documents with 
different PIDs.

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678