Re: Unique handle generation

[Martin Oldfield <m@mail.tc>]

>>>>> "Michael" == Michael Mealling <michael@bailey.dscga.com> writes:

    Michael> On Thu, Mar 15, 2001 at 05:25:10PM +0000, Martin Oldfield
    Michael> wrote:
    >> >>>>> "Michael" == Michael Mealling <michael@bailey.dscga.com>
    >> >>>>> writes:
    Michael> Please. No. I've been involved in a lot of these XML/URI
    Michael> discusions and you really don't want to do this. Do you
    Michael> really want to have your system to have to deal with a
    Michael> registry using "mailto:joe@aol.com" as its registry
    Michael> identifier? Allowing any URI means you allow _ANY_ URI
    Michael> here.  The issues surrounding the nearly 100 different
    Michael> unregistered URIs that folks are using with no
    Michael> coordination and several conflicts [1][2] make this a
    Michael> currently very badly managed space. This is the
    Michael> identifier the _entire_ provreg system is going to depend
    Michael> on at its _core_. You really don't want it based on such
    Michael> loose identification scheme...
    >>
    >> So much for that daft idea then!

    Michael> Sorry about the bluntness there. The pain that was felt

Not at all: I'm just hope you didn't need too much anti-histamine.. I
think your experience is really valuable, and short-circuits a whole
bunch of ignorant waffling.

    Michael> in many different areas created a severe alergic
    Michael> reaction. ;-)

    >> If you'll indulge my stupidity for a little longer,

    Michael> Not stupidity! Its a good idea that has merit but
    Michael> experience is in the process of teaching us where that
    Michael> idea is useful and where it causes problems... (As an
    Michael> aside, I'm involved in the W3C URI Interest Group where
    Michael> we're discussing exactly these kind of issues and
    Michael> hopefull we'll be able to issue some guidance soon).

Splendid. 

    >> would you objections persist if the URI had to be an http:
    >> thing, and the target of the URI had to deliver a particular
    >> document ?

    Michael> That's a step in the right direction, yes. The other main
    Michael> objection is that of using the 'http' scheme which
    Michael> contains a domain-name.  A domain-name is too fragil of
    Michael> an identifier to use for the entities that actually
    Michael> manage those domain-names (i.e. the registries involved
    Michael> here should last longer than the average life of their
    Michael> default domain-names).  IMHO, you want a scheme that a)
    Michael> has uniqueness b) has persistence and c) does not have
    Michael> domain-names in it.

I see your point of view, but isn't it really hard to escape domain
names somewhere ? 

Consider a scheme where the registry-handle comes from some central
registry. Don't you then need to have some magic URN which contains a
list of registry handles and tells the client how to handle them ? The
alternative would appear to be giving each client a list of registry
handles and details of how to handle them: perhaps a list is unavoidable
because I'm sure that some clients will want to only trust certain
registries.

If we do want to have a automated scheme for resolving a handle though
, then presumably we need some central root which knows how to direct
all the registry handles, or the handle itself has to tell us where to 
go. 

If that's right then isn't this a trade-off between having registry
handles issued by a central authority who has to keep their URN alive
forever, or having a multiplicity of URNs but letting everyone make up
their own registry handle ?

    Michael> But still, once you limit it like this you've gotten
    Michael> yourself back to an identification scheme that is
    Michael> specific to your system (a good thing) that happens to be
    Michael> a URI (also a good thing).

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.