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

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Old thread alert!

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJE1NAAoJEOoGpJErxa2pNSoP/RJgsEs2dukr940ZBpU6tCR0
Hr/Xb7M4M7LrWQPV5lhFx5sEIQFBai/+Q/GhHOKkkyIeRrbR1D2sO/1GFyW93lqX
hOHJgWEq3vhPTkHBWj+38J3ndokLBXi/lVoYrD8rk6jC6VXszXBkPXsf4pmKTjFN
sQH+QV+2pZ70k/b/ZjLmyKVfYUrJJ0WEkvyRqUGaQYCKoZHG7OOzBrDG7sS7XEUC
GzHKPuoVVFdFiqeH9wE4Hz3fb+fgAEOGY2UNnM/Z4ZHnG+DB0qzID3nXARHWpGGh
FlGlzk1RY9Lwqp+mEzgWK7rl/3Fm39nWckrHQGDxeJWK+klD8n12CSfNNNubombR
j1YORDqsiVXtQ9EsZgQPVqZ9WvSTjYeYWB0HDpi8in6gniHAyE90Pox6hgnIVSY1
IyRIBfWJE+QNhlpCltR8/nYif48KcDcV4bkJgW6gQnAUC6XO/u22/bZQZS2eKENz
G1ccNkh981VGlnrGtS1nqP9MzGOwyvFjOYSrNkwBqGVG486wbUSmiOCfGe/hZRh4
0XnIGkerFTUeHLF98ED+ZoRmcQGBxn+5y9hz+wauAUIlW6/LRh3K6YfQQUewpHW9
pWnaALOqAG0jaIBqUXKi2P05d5UbD5H6So1teoKgkkivRIT7SXsKNg/mNy8nDxCN
yuQ627UL2DerIs1x5AHx
=zJ13
-----END PGP SIGNATURE-----