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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 21:13:01 -0700

Old thread alert!

On 11/26/12 8:47 AM, Ted Hardie wrote:
> On Sun, Nov 25, 2012 at 4:47 AM, Larry Masinter
> <[email-masked]> wrote:
>> 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".

Larry, we know that in practice most URIs are not of the form
"blah:stuff" but "blah:stuff.com/heres-the-stuff". I agree with Ted
(below) that DNS domain names might change hands more frequently than
URN issuers.

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

Ted, with respect to permissiveness, do you mean registration of URI
schemes or URN namespaces (or something else)?

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

Agreed.

And to Larry's original point, RFC 2141 says only that URNs) are
*intended* to serve as persistent, location-independent resource
identifiers. It doesn't guarantee that those intentions will be
achieved in reality.

Here's my interpretation (which doesn't necessarily take into account
the history of discussion on this topic because I wasn't involved back
then and I lack the full context that Larry, Ted, Leslie, et al. possess):

1. Persistent doesn't mean permanent (since nothing is permanent), it
only means long-lived (or longer-lived than a location-dependent
identifier).

2. Location-independent means the resource is not tied to a particular
path at a particular DNS domain name via a particular access method.

IMHO, persistence and location-independence are closely intertwined.

I also think that it's good to have identifiers that are closer to
being persistent and location-independent (or farther from being
ephemeral and location-dependent), and I think that URNs as defined in
the existing specs fit the bill. All we're trying to do here is
modernize the definitions a bit to bring them in line with RFC 3986,
RFC 5226, etc.

Larry, do you have proposed changes to the text that would clarify the
status of URNs in your mind?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Feb 2013 00:43:19 -0500

> only means long-lived (or longer-lived than a location-dependent
Actually the binding between a URN and the resource, once assigned, was 
indeed intended to be permanent.  That doesn't mean that the resource is 
permanently accessible (or ever accessible).   And it was always 
understood that the resource could change (in the sense of being 
replaced with a later version of the same thing).   But the URN should 
never be reassigned to a resource that is inconsistent with the original 
binding.
> path at a particular DNS domain name via a particular access method.

It means all of that and more.   For example, it also means that the 
meaning of the URN is the same from every location in the network.
> IMHO, persistence and location-independence are closely intertwined.

Yes, location-independence is a necessary condition for persistence.
> modernize the definitions a bit to bring them in line with RFC 3986,

Of course I realize that no protocol specification can force any 
particular URN to be either persistent or location-independent 
forever.   But that's not a justification to revise the URN 
specifications to dilute the intent of URNs.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Feb 2013 20:51:07 -0700

On 2/19/13 10:43 PM, Keith Moore wrote:
>> Here's my interpretation (which doesn't necessarily take into
>> account the history of discussion on this topic because I wasn't
>> involved back then and I lack the full context that Larry, Ted,
>> Leslie, et al. possess):
>> 
>> 1. Persistent doesn't mean permanent (since nothing is
>> permanent), it only means long-lived (or longer-lived than a
>> location-dependent identifier).
> Actually the binding between a URN and the resource, once assigned,
> was indeed intended to be permanent.  That doesn't mean that the
> resource is permanently accessible (or ever accessible).   And it
> was always understood that the resource could change (in the sense
> of being replaced with a later version of the same thing).   But
> the URN should never be reassigned to a resource that is
> inconsistent with the original binding.
> 
>> 2. Location-independent means the resource is not tied to a
>> particular path at a particular DNS domain name via a particular
>> access method.
> 
> It means all of that and more.   For example, it also means that
> the meaning of the URN is the same from every location in the
> network.
>> I also think that it's good to have identifiers that are closer
>> to being persistent and location-independent (or farther from
>> being ephemeral and location-dependent), and I think that URNs as
>> defined in the existing specs fit the bill. All we're trying to
>> do here is modernize the definitions a bit to bring them in line
>> with RFC 3986, RFC 5226, etc.
> 

Agreed on all points.

I'm not yet sure how best to capture some of this in the spec, but
I'll give it some thought and try to return with some proposed text.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Feb 2013 14:06:34 -0800

On Tue, Feb 19, 2013 at 8:13 PM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Old thread alert!

> schemes or URN namespaces (or something else)?
I think my main point is that we now see the registration process differently.
We want people to notify the community that they are using a particular
scheme, so that we can avoid collision; to maximize that, we're minimize
other sorts of review (including pushback like "this should be  a URN").
Anyone can make the same claims about a new URI scheme as are made
for a URN under that approach.

Ted