Re: Unique handle generation

[Michael Mealling <michael@bailey.dscga.com>]

On Thu, Mar 15, 2001 at 04:40:33PM +0000, Martin Oldfield wrote:
> >>>>> "Michael" == Michael Mealling <michael@bailey.dscga.com> writes:
> --> snip <--
>     Michael> My recommendation is this: use the
>     Michael> <registry-handle>-<local-handle> syntax where
>     Michael> registry-handle is registered with the IANA and
>     Michael> local-handle is a unique identifier assigned however the
> 
> Rather than having an IANA registered registry-handle, can't one
> simply use a URI ? This idea is used by XML namespaces [2], and
> similar to Rick Wesson's idea [3]. 

And suffers from the same problems that XML Namespaces has:
If you allow any URI here you end up with unstable identifiers.
_We_ all know how unstable domain-name based identifiers are. It
seems kind of silly to base our identification structure on something
that we are in the process of managing and thus changes out from underneath
us. A good example: is the Verisign registry required to still be 
known as networksolutions.com? Shouldn't it still be internic.net since
that's what the registry originally was known as?

You _could_ restrict it to a particular URI scheme (which IMHO is what
XML Namespaces wanted to do but couldn't due to some political issues).
But, IMHO, this is overkill. What would make sense is turn the tables
around and turn the handle into a URI (i.e. a URN) which would allow
you to do some interesting (but probably not core) things.

> From the handle perspective I don't think it's necessary that the URI
> actually points at anything, though of course this could happen in
> future---this actually mirrors the XML situation (see
> e.g. [4]). Following the XML example, the registry handle URI would be
> a natural place to store things like a specification of the registry,
> its policies and so forth.

Sure, but is that an argument for being able to turn a handle into a 
URI fairly easily not making handles be _any_ URI. We're not designing 
XML here, just a fairly task specific system for provisioning records 
in databases.

> Are there lessons to be learned from XML namespaces ? I've done little
> more than browse the FAQs [5] but I'm sure there are people here much
> more knowledgable.

One of the issues that XML is learning now is that you should only
allow a field to be _any_ URI when you're application is completely aware
that it could be identifying ANY sort of resource (abstract or otherwise)
and in most cases the entity that originally bound the URI to that 
Resource had no intention of it being used as an identifier in some
other system. In the case where some field is a core protocol concept (such as
in RDF or XML Schemas) its a good idea to limit the types of URIs you 
can safely use in that field. Thus, IMHO, the registry part of the
name should not be a URI but instead the whole thing should be capable
of being turned into a specific type of URI (IMHO, a URN but that's just
my opinion).

>     Michael> registry sees fit. Then, to handle equivalence between
>     Michael> registries, the base schema of all objects (if that has a
>     Michael> concept here, I haven't looked yet) allow for a way for
>     Michael> one object to say two things: "Hey, I'm also known as
>     Michael> FOO-BAR, BAZ-BAR, and HOMER-DONUTS." as well as "I was
>     Michael> also known as PREHISTORIC-CAVEMAN at sometime in the
>     Michael> past". The one thing this fixes is that equivalence may
> 
> Presumably this implies that the local-parts can't be reused ?

I think that's a rough concensus here for that idea. I'm pretty sure its 
an informal policy among most of the existing registries/registrars....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com