Re: URx Questions

On 2002-01-22 19:25, "ext Tim Kindberg" <timothy@hpl.hp.com> wrote:

> At 08:46 AM 1/22/2002 -0500, Daniel R. Tobias wrote:
>> Actually, the "guarantee" of uniqueness is only as good as the
>> minting authorities make it... ...
> 
> ... I take it for granted that identification relies on many
> factors that have to do with 'good practice'. As systems designers we can
> only try to create openings that prove (or don't prove) to satisfy a need
> and that are within the limits of people's budgets and competencies.

In principle, I fully agree, though in practice, I prefer
solutions that facilitate and encourage what is percieved
as optimal without mandating or forcing what is percieved
as optimal, because needs/understanding change and
needs/opinions vary.

Thus, you can create an 'hrn:' that is, according to the UUID
specification, guarunteed to be globally and temporally unique
(presuming a valid implementation) while still adding mnemonic
components to it if desired. E.g.

  hrn://-/f81d4fae-7dec-11d0-a765-00a0c91e6bf6

or

  hrn://-/f81d4fae-7dec-11d0-a765-00a0c91e6bf6/Chapter1

One can also, as per 'tag:', anchor one's 'hrn:' temporally by
date, e.g.

  hrn://abc.com/2002/FinancialReport/Introduction

or at higher resolution

  hrn://abc.com/2002/01/22/FinancialReport/Introduction

Or one can use other means to denote temporal ordering, such
as version numbering, e.g.

  hrn://abc.com/InductionGuide-v2.7

Or one can use proprietary components that ensure temporal
uniqueness, such as managed sequences of identifiers, e.g.

  hrn://abc.com/abcid_881819923819/Chapter1

Or one can simply trust that the name is so significant within
the context of the minting authority that it will never be
reused, and thus ambiguity will never arise, e.g.

  hrn://john.doe@abc.com/resume

In short, it's up to the minting authority to decide just
how strict or loose the requirements are for temporal and/or
global uniqueness -- with each of the options having more or
less overhead to use (granted, some discussion regarding
global and temporal uniqueness and how to best achieve that
would likely be a good addition to the final 'hrn:' RFC, and
I've made a note of that).

A generalized URN scheme must provide the utility and
flexibility needed to accomodate common naming practices while
still providing for the needs of most or all users, including
absolute temporal and global uniqueness if so desired/needed.

With regards to temporal anchoring, 'tag:' seems to me to be
too "mothering" and not general enough. And as has been pointed
out, does not provide a form that garuntees against accidental
collision within the same authority (e.g. UUID). Thus, 'hrn:'
is both more general and more precise than 'tag:'.

If absolute temporal and global uniqueness is paramount, there
are other URN schemes that can be used, and agencies that will
ensure that uniqueness for all instances of such schemes no
matter what, but for a price (e.g. DOI, ISBN, etc.).

>>> By the way, tag: is in the RFC editor's queue. It's also somewhere in the
>>> urn nid registration process.
>> 
>> I'd like to know just "what's the deal" with these dual URN namespace
>> / URI scheme registrations.  ...
> 
> ... By the way, we
> view the one namespace as a simple embedding of the other, so tag:x and
> urn:tag:x are the same _identifiers_ (I didn't refer to bindings), for all x.

It's nice that *you* view them as the same, but how are applications
(or humans) to know that they are the same?

I think that the IETF should *heavily* discourage, if not disallow
dual registration of equivalent URI and URN NID schemes.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 23 January 2002 05:39:15 UTC