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

[Ted Hardie <[e-mail]>]

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

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.

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

regards,

Ted

> 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.
>
>
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:[e-mail]]
>> Sent: Monday, November 19, 2012 8:39 AM
>> To: Larry Masinter
>> Cc: Renato Iannella; [e-mail]
>> Subject: Re: [urn] call for comments: an alternative 2141bis document
>>
>> On Mon, Nov 19, 2012 at 1:58 AM, Larry Masinter <[e-mail]>
>> wrote:
>> >> Hi Larry....as we all know, it is impossible to say that _anything_ will be
>> >> 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