[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: ietf-provreg@cafax.se
From: Martin Oldfield <m@mail.tc>
Date: Fri, 9 Mar 2001 16:32:49 +0000 (GMT)
In-Reply-To: <DF737E620579D411A8E400D0B77E671D75075B@regdom-ex01.prod.netsol.com>
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Unique handle generation

>>>>> "Scott" == Hollenbeck`, Scott <shollenbeck@verisign.com> writes:

--> snip <--

    >>
    >> 1. Registry generates it, and sends it the registrar.
    >>
    >> 2. Registry generates it but tries to accomodate an optional
    >>    hint
    >> supplied by the registrar.
    >>
    >> 3. Registrar generates it, and submits it to the registry. If
    >>    the
    >> local-part isn't unique then the registry just refuses, and the
    >> registrar tries again.
    >>
    >> Roughly there's a progression here from registry- to registrar-
    >> generated handles: where's the optimum ?
    >>
    >> (2) is a special case of (1) because (2) places no requirement
    >>     on the
    >> registry to accomodate the hint; (3) seems slightly dangerous
    >> becuase in the general case it might be hard for the registrar
    >> to see why his handle isn't valid and so pick one which did
    >> work.
    >>
    >> Comments ?

    Scott> Personally I like (3).  We already have a "does it exist"
    Scott> query mechanism defined in the <ping> command, so a
    Scott> registrar can check multiple values before trying to create
    Scott> anything.  If they try to create one that already exists,
    Scott> an error code will identify the "not unique" problem quite
    Scott> definitively.  This will allow a person to have some
    Scott> control over the local part, which may help facilitate use.

I quite agree that it's good for the registrar to be able to influence 
the local-part, which was the idea behind (2).

I'm not sure that just being able to see if a handle is taken is
enough though. Suppose the registry requires that the handles have
some sort of internal consistency checksum, then it's not enough to
know that a local-part is free: rather one needs to know if the
local-part is free and valid. Blind guessing might take a while to hit
on a suitable value, and it seems messy for every registrar to have to
embed the algorithm in their code.

By contrast the registry is well-placed to generate a local-part which
both conforms to its own criteria of validity, and which pertains to
the registrar supplied hint.

For example, suppose you supplied the hint `Hollenbeck' to a registry
which wanted local-parts to be lower-case, 12 characters long and to
have a certain checksum: it would be simple for the registry to return
a local-part of `hollenbeck34'. 

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.


Home | Date list | Subject list