Subject: Re: [urn] call for comments: an alternative 2141bis document

From: Larry Masinter <[email-masked]>
Date: Sun, 11 Nov 2012 00:13:31 -0800

For the record:

Personally, I think that the definition of URNs in 2141 was a mistake, and that santandre's document doesn't go far enough. URNs may have originally intended to be "persistent" and "location independent", but in practice, they intrinsically no more or less persistent or location independent as any other URL, they just happen to start with the "urn:" scheme and have a different generic syntax.

In fact, the only thing that distinguishes urns, in general, is that they form a consistent way of important an externally managed namespace into the URI space.

So I would update 2141 to say that there is a URI scheme "urn:" which is useful when there is a naming authority which takes responsibility for determining the interpretation of names. I might also note that there was some confusion about the role of urns in the past, with the hope that they could provide some "persistence", but the distinction is illusive.  One could have just made up URL schemes (use issn:.... instead of urn:issn:...) but the consistency of knowing the nature of the URI might be useful and avoid proliferation of schemes.

I might apologize for Urn:uuid as a mistake (since there is no authority), and point to a few URI schemes which are not normally thought as being "Internet" (tel:, although that's increasingly resolvable.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andrew Newton
> Sent: Thursday, October 25, 2012 11:35 AM
> To: [email-masked]
> Subject: [urn] call for comments: an alternative 2141bis document
> 
> All,
> 
> We have received a request for this working group to consider an
> alternative to its adopted 2141bis document
> (draft-ietf-urnbis-rfc2141bis-urn-03). That alternative is
> draft-saintandre-urnbis-2141bis-00
> (http://datatracker.ietf.org/doc/draft-saintandre-urnbis-2141bis/).
> Additionally, some reviewers of our adopted document have expressed
> concern regarding its unnecessary wordiness, especially in comparison
> with the alternative.
> 
> Can participants of this working group please review both documents
> and express opinions and provide comments as to the direction desired
> for this working group in regards to a 2141bis RFC?
> 
> The two documents can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/
> http://datatracker.ietf.org/doc/draft-saintandre-urnbis-2141bis/
> 
> We will use the IETF standard of rough consensus to determine the way
> forward.
> 
> Finally, should the working group desire an alternative approach, we
> intend to preserve and publish the historical and non-normative
> information found in our current document. This information is
> valuable and important.
> 
> -andy
> co-chair, URNBIS
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Renato Iannella <[email-masked]>
Date: Wed, 14 Nov 2012 10:55:21 +1000

> Personally, I think that the definition of URNs in 2141 was a mistake, and that santandre's document doesn't go far enough. URNs may have originally intended to be "persistent" and "location indepe…

Hi Larry....as we all know, it is impossible to say that _anything_ will be persistent (even beyond our lifetimes) in this industry.

But I think that at least URNs _try_ to highlight to URN operators that they need to consider longevity (Sec 5.1 of RFC3406bis [1])
and the fact the URNs are not dependent on the DNS and the opaque NSS help towards that goal....but still requires ORG support for this to be realised (hence a dependency on ORG persistence).

Perhaps we can update 3406bis and 2141bis along these lines. That is, qualify the "persistent, location-independent" statement with qualification. 

Cheers...
Renato Iannella
Semantic Identity
http://semanticidentity.com
Mobile: +61 4 1313 2206

[1] http://tools.ietf.org/html/draft-saintandre-urnbis-3406bis-00

---

From: Larry Masinter <[email-masked]>
Date: Mon, 19 Nov 2012 01:58:41 -0800

> Hi Larry....as we all know, it is impossible to say that _anything_ will be
> persistent (even beyond our lifetimes) in this industry.
http://masinter.blogspot.com/2010/03/ozymandias-uri.html

> But I think that at least URNs _try_ to highlight to URN operators that they need
> to consider longevity
http://tools.ietf.org/html/draft-saintandre-urnbis-3406bis-00#section-5.1

There is no clear line between meeting the requirements for "formal" and not; we (the IETF reviewers) are being asked to judge something we have little qualification to judge, namely the likely longevity of an organization's ability to "resolve" names for some period of time (how long?), and whether that registration and resolution service will remain "open" (in what way?) for an indefinite amount of time (how long?).

I like the criteria, just I'm uneasy about IETF judging them without bikeshedding.

> and the fact the URNs are not dependent on the DNS and the opaque NSS help
> towards that goal....but still requires ORG support for this to be realised (hence
> a dependency on ORG persistence).

I assume you mean "organizational" by "ORG" and not something more formal.
Of course URLs aren't all dependent on DNS either.  You're not saying why tel: is a URI scheme and not a URN namespace? 
r
I'm not sure what you mean by "opaque NSS".

> Perhaps we can update 3406bis and 2141bis along these lines. That is, qualify the
> "persistent, location-independent" statement with qualification.

I think it's a mistake to believe that URNs accomplish either of those, and people often skip the qualifications. URNs are not persistent. And "location-independent" cannot be determined.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Nov 2012 08:39:06 -0800

>> persistent (even beyond our lifetimes) in this industry.

While I agree that there is no way to say that anything aiming to be
persistent will succeed, I do think it is useful to capture the answer
to the question:  will this identifier ever by reassigned in the
normal course of business?  There are lots of reasons why you can be
wrong in the answer you give, but the answer is useful.

This is also, oddly enough, why I think UUID URNs are just fine, even
though they do not have an organizational guarantee--the cryptographic
guarantee they provide is at least as good as the typical
human-managed system.  So I can look at one in a system and understand
that it is meant to be unique.

Just my personal view, of course,

Ted

---

From: Larry Masinter <[email-masked]>
Date: Sun, 25 Nov 2012 04:47:50 -0800

I'm not sure how useful it is to "capture the answer to the question:  will this identifier ever by reassigned in the  normal course of business?"

I think the question was "why bother with the extra four 'urn:' letters, rather than just invent a new scheme?" and it's as useful to say that about  blah:stuff as it is about  urn:blah:stuff, and if you are handed a URL of the form "urn:blah:stuff" where you know nothing about "blah", you have no more information than you would have given "blah:stuff".

(blah = uuid & stuff cryptographically securely randomly generated or not).

I think you will have trouble defining "reassigned" and "normal course of business"... 

During the normal course of business http://host/path  always means  
   >>> talk to the host named "host", using whatever protocol is currently meant by "http", asking for "/path" <<<<

You probably mean something else by "reassigned", but there's a devil in the details of what it means in operational terms that make sense.

The theory I'm working on links persistence to meaning, in that, within a communication from Alice, through a repository R, to Bob,
that includes a URL/URI/URN/IRI

A --- U ---> R 
R --- U -->  B

Where the two transactions are time-offset, that the intention of meaning by A for U is tied directly to the expected persistent behavior of B when interpreting U. 

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Monday, November 19, 2012 8:39 AM
> To: Larry Masinter
> Cc: Renato Iannella; [email-masked]
> Subject: Re: [urn] call for comments: an alternative 2141bis document
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Nov 2012 07:47:23 -0800

> I think the question was "why bother with the extra four 'urn:' letters, rather than just invent a new scheme?" and it's as useful to say that about  blah:stuff as it is about  urn:blah:stuff, and…

If you mean, could the group have made "This is guaranteed not to
change, for some value of guaranteed" part of the meta-data in the
registration, rather than something signaled in the URI string, sure.
But as I'm sure you remember, there were visions at the time of using
a different resolution service to find instances of the
thing-that-a-urn-represents; had that turned out to be a common
resolution mechanism, then having a common signal to use it makes
sense.  That's not quite the language in RFC 2276, but I think the
presumption of an RDS was a driver for using a unique string.

Is it worth changing now, and converting existing URNs?  Certainly
not, as that would violate the principle they were built under.  Could
you now build a URI that had the same characteristics as a URN, but
did not use the string?  Yep.  The IESG historically would have asked
you "why isn't this a URN?", but since we're making registration
highly permissive, I'm not sure that they would really need an answer.

> You probably mean something else by "reassigned", but there's a devil in the details of what it means in operational terms that make sense.

I mean "the registration authority, the laws of physics, or some
mathematical principle state that if I have associated *this* URN with
*that* resource, it will never be associated with a different resource
during the likely lifetime of our civilization".  DNS names are
re-assigned far more frequently than that.

regards,

Ted