Subject: [urn] New urns-are-not-uris draft

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jul 2014 02:41:21 -0400

Hi.

I just posted a new version of
draft-ietf-urnbis-urns-are-not-uris.  Changes are listed in
Appendix C of the draft but, basically, there is nothing new in
it that has not already been discussed on-list.  Considerable
text (including Appendices A and B) and a new Section 2 have
been copied from list discussions (and lightly edited) in the
hope of drawing material together and helping to focus
discussion in Toronto.  Much of that material should come back
out, as indicated in the text, so it is probably not worthwhile
to spend time wordsmithing it unless that is needed to improve
clarity of discussions.

   john

p.s. Don't bother reporting "Appendix Appendix A" (or "B") if
you happen to notice it.  XML2RFC ticket #266.

---

From: Larry Masinter <[email-masked]>
Date: Sun, 6 Jul 2014 02:14:38 +0000

Right now, we have the category of strings that are URIs, which start with something:, of which some start with 'urn:' and some don't. The ones that start with 'urn:' we say are URNs. The ones that start with 'something-else:' we say are URLs.

The proposal is to secede from this union and say "no, no more unifying", some strings are URNs (and start with 'urn:'? ) and other strings are URLs.

But there are existing systems that accept either -- XML namespaces are deployed that use 'urn:' URNs and others use 'http:" URLs. We'd have to make up a new kind of union category 'either URN OR URL'.

If you called that union 'URI' we'd be back where we started.
===============
It isn't true that ISBN numbers never change. They change rarely, perhaps. A primary use  of ISBN was as bookstore stock and pricing unique key. So if a book is printed with multiple color covers, they might use the same ISBN number. New printing, perhaps a minor printing flaw fixed, ditto. The permanence and meaning of this kind of identification for documents will change even further. Not every blog post gets its own identifier, with many information tools, 'location' is meaningless. You may think this is a minor point or these are corner cases, but I think they're central. The well-ordered world wished for isn't there.

The document consistently attributes to "all URIs" properties that are only true of a few URI schemes. There are plenty of name-like URLs that are not URNs, tag:, data:, uuid: and many others.

Comments linked to the text:

# 1. Introduction
The names of categories of identifiers "name-type" and "location-based" are design concept ideas and not properties of the identifiers themselves. 

# "Impractical to constrain URNs to syntax and high-level semantics of URLs" 
What constraints there are can changed  without seceding URNs from the URI union. As far as I can tell, the only syntactic changes wanted is to allow "#" for fragments and "/" for hierarchy. If this is necessary it might require an update.

# "Generalization ... has failed ..."
I don't see any use cases where splitting URNs from URIs reduces failure. If there are  failures, they are intrinsic.

# "... are simply different creatures ..." 
The boundary between locator and name is completely blurred and there are endless examples where the pun is a fundamental feature: that the same URI functions as a name in some contexts and a location in others.  XML namespaces are a clear instance where both http and urn URIs are used uniformly.

# Giving location information a role in identification ...force libraries to adopt different policies for printed and digital material

Digital material is massless. Of course libraries need different policies. This has nothing to do with URNs.

BTW, this is the first mention of libraries, what do you mean by the term, where did they come from, and what are their requirements?

# "Let us assume that ten people independently upload a copy
#  of an electronic book into different locations in the Web.  Are all
#   these ten URLs valid identifiers of the book?"

If you ask "is A an accurate identifier for B" the answer is "no": the only accurate identifier for what B identifies is B, everything else is identifies differently. 
If you asked "can any of these ten URLs be used as an identifier for B", yes, can be.

If you want a system of generating IDs and embedding them into digital material, 
I'd recommend looking at XMP (eXtensible Metadata Platform) which embeds 
a GUID-based InstanceID and DocumentID in each file or compound file collection
as an example of locationless identifier.

Ten people generate online material from a paper book: then all are different, related
Documents, they're not interchangeable for all document purposes.

Relation to ISBN and other info such as title? The ordinary one, ISBN, title, etc
Are additional metadata, linked by a wide variety of mechanisms. 

1. ".. managed process .. A user cannot determine whether some URI is reliable or not"

You need clarify what you mean for a URI/URL/URN to be "reliable".  URNs can
fail (even National Libraries can fail when nations fail), URLs can be very
long lived ("data:").

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Jul 2014 12:43:53 -0400

--On Sunday, 06 July, 2014 02:14 +0000 Larry Masinter
<[email-masked]> wrote:

> Right now, we have the category of strings that are URIs,
> which start with something:, of which some start with 'urn:'
> and some don't. The ones that start with 'urn:' we say are
> URNs. The ones that start with 'something-else:' we say are
> URLs.

Some say they are URLs.  Others say that, e.g., strings that
start with "SIP:" are just a different type of URI -- neither
URNs nor URLs.  I note that the RFCs are written in a way that
doesn't make "SIP:..." a URL; they just leave the question open.
The separation draft doesn't change that.

> The proposal is to secede from this union and say "no, no more
> unifying", some strings are URNs (and start with 'urn:'? ) and
> other strings are URLs.

(or still "generic URIs".)

> But there are existing systems that accept either -- XML
> namespaces are deployed that use 'urn:' URNs and others use
> 'http:" URLs. We'd have to make up a new kind of union
> category 'either URN OR URL'.

If the code doesn't change, nothing else changes either.   "Have
to" is a little bit of a strange term in this context.  If, in
practice, their code implemented PHB's definition of a URI,
i.e., 
   method:<stuff>

rather than the 3986 definition, then nothing would change.  If
the code really understood only "http:" URLs and 2141 URNs, then
"SIP:" doesn't work and any replacement to 2141 would involve
changing the code.  

> If you called that union 'URI' we'd be back where we started.

No, we wouldn't, and that is exactly the point.  If one had that
situation and called the union of "http:" URLs, other kinds of
USLs, other kinds of what are now called URIs, and URNs "URI",
we'd be an a state where the semantics (and syntax, but that is
a tad less important) of 3986 didn't constrain non-HTTP URIs.
We would _just_ have a generic term.

Let me a bit more clear about one thing.  I really don't like
kludges like Dale's proposal for extensive use of %.  I think
they are ugly, hard to understand and debug, and an invitation
to future trouble especially in the absence of _very_ careful
implementations.  But, if 3986 were free of explicit and
implicit semantic constraints, I'd probably be arguing to living
with it just to avoid making disruptive changes.  However, those
semantic constraints and terminology are in place and
_something_ is needed to allow the perceived needs of legitimate
and experience communities to be accommodated.   Since some
changes --starting with either a separation or, as Lars
effectively suggested, revising and updating 3986 to take the
semantics and over-specific terminology out -- are needed, I
think it is worth at least asking the question of whether we can
create a URN specification that is kludge-free and that,
consequently, has a better expectation for a long lifetime than
it might otherwise.

> ===============
> It isn't true that ISBN numbers never change. They change
> rarely, perhaps. A primary use  of ISBN was as bookstore stock
> and pricing unique key. So if a book is printed with multiple
> color covers, they might use the same ISBN number. New
> printing, perhaps a minor printing flaw fixed, ditto. The
> permanence and meaning of this kind of identification for
> documents will change even further. 

Based on reading the standard (have you done that?) and a few
discussions with the registration agency, I think your
interpretation above is wrong or at least misleading.  But that
is not an area where I claim expertise so I'll let others debate
it with you if they are so inclined.  A few of your comments
below been elided.  I hope others with more in-depth expertise
will respond to them, especially if they believe the topics have
not been adequately covered already.

In particular, your excerpts from what is now Section 3 are
about text for which Juha provided that starting point and that
has been, IMO, extensively discussed on-list.  If he tells me
that I misinterpreted his intent, I will be happy to revise as
needed (also, of course, if Andrew tells me the WG consensus is
different).  But, unless you are ready to engage with his
position, and, IMO, do so with equal experience and authority,
repetition of the same assertions this just leads us in circles.

> Not every blog post gets
> its own identifier, with many information tools, 'location' is
> meaningless. You may think this is a minor point or these are
> corner cases, but I think they're central. The well-ordered
> world wished for isn't there.

I think that may be true but is certainly irrelevant.  See
above... and Juha's repeated comments about managed processes.

> The document consistently attributes to "all URIs" properties
> that are only true of a few URI schemes. There are plenty of
> name-like URLs that are not URNs, tag:, data:, uuid: and many
> others.

The "all URIs" problem is a consequence of the language of 3986
(on which I note your name appears) and not the present document.

> The names of categories of identifiers "name-type" and
> "location-based" are design concept ideas and not properties
> of the identifiers themselves. 
> 
># "Impractical to constrain URNs to syntax and high-level
># semantics of URLs" 

> What constraints there are can changed  without seceding URNs
> from the URI union. As far as I can tell, the only syntactic
> changes wanted is to allow "#" for fragments and "/" for
> hierarchy. If this is necessary it might require an update.

Other changes may be needed - see the document at -01 and the
correspondence on the list.  More important, my opinion (perhaps
wrong) and that of Barry and Pete (unless I've misunderstood) is
that there is insufficient energy in the IETF to undertake a
3986bis, or even a substantive and detailed update, and more it
to completion in a reasonable amount of time.  The separation
model is just a pragmatic way to work around that problem
without holding the work of the URN WG up for an additional
extended period -- and allowing the odds of a fork in the
standard by another body that doesn't need to debate these
niceties of definition to rise considerably.

> I don't see any use cases where splitting URNs from URIs
> reduces failure. If there are  failures, they are intrinsic.

The failure is to come up with a syntax and set of semantics for
URNs that meet the perceived needs of the important parts of the
URN community without violating the constraints of 3986.  I
thought that was clear; if not, I apologize and will make
another pass through the draft.

> The boundary between locator and name is completely blurred
> and there are endless examples where the pun is a fundamental
> feature: that the same URI functions as a name in some
> contexts and a location in others.  XML namespaces are a clear
> instance where both http and urn URIs are used uniformly.

See prior comments (above and on the list) about the perceived
needs of legitimate and experienced communities.   You, of
course, get to disagree, but that doesn't seem to affect their
perceptions.  And, again, the IETF gets to either adapt or risk
(I believe "guarantee", but could be wrong) an externally-forked
standard.  This is not an instance where the IETF gets to say
"no, you shouldn't do that, or believe that, so don't" and
expect an established community with centuries of experience to
pay any attention.

>...

best,
   john

---

From: Juha Hakala <[email-masked]>
Date: Mon, 07 Jul 2014 16:02:29 +0300

Hello,

> not been adequately covered already.

I was a member in the working group which wrote the current version of 
the standard.

ISBN Manual 
(https://www.isbn-international.org/sites/default/files/ISBN%20Manual%202012%20-corr.pdf) 
and the standard itself provide detailed guidelines on how to apply 
ISBNs. Every well managed identifier system should have published 
guidelines document.

An ISBN which has been assigned to a book will never change. The ISBN of 
Food composition data interchange handbook published by United Nations 
University in 1992 is and will always be 92-808-0774-9. This ISBN will 
never be reused (assigned to another book) and this version of the 
handbook will never get another ISBN.

Chapter 5 of the ISBN manual (Application of ISBN) says that if there 
are no changes to the content and physical form (or if just some 
misprints are fixed), the same ISBN can still be used for reprint. But 
if there are substantial changes to the intellectual content, new ISBN 
is required. ISBNs are usually accompanied with detailed metadata which 
describes the difference between two editions (e.g. 2nd, revised ed.).

Had the Food composition data interchange handbook been published in 
different formats (hardback, paperback, PDF and so forth) each one of 
them would have received its own ISBN.

ISBN community, like other communities using traditional identifiers, 
does not need URNs to extend the scope of the existing identifier system 
or to change its current identifier assignment policy. URNs are needed 
mainly in order to make the existing identifier systems actionable in 
the Internet. Theoretical discussion in this list on the principles of 
naming / identification has therefore not been particularly helpful.

Whether the current principles for assigning ISBNs are correct from IETF 
point of view (whatever that means), or the fact that it is possible to 
misuse ISBNs (some publishers especially in the U.S.A. would like to 
give the same ISBN to all digital versions of a book) is, IMO, not 
something that needs to be discussed in URNBIS / IETF. IETF does not 
have a mandate to change the policy of ISBN assignment. And there are 
other URN namespaces out there which are more problematic than URN:ISBN 
from management point of view.

> different).

No, John has interpreted my intent correctly.

>   But, unless you are ready to engage with his

The world as a whole is not well-ordered, but there are parts of it 
which are reasonably well managed and orderly. And it is in these well 
managed parts of the world where URNs and other persistent identifiers 
are most urgently needed. If there is no requirement to preserve a 
document for long term (beyond the life time of technologies such as 
HTTP) then even protocol dependent and un-managed "identifiers" may be 
sufficient.

A blog post in the web is not persistent, but a blog post harvested into 
the national library's web archive will be preserved for long term, and 
is likely to receive a persistent identifier as well.

Juha
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  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