[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:01:38 +0000 (GMT)
In-Reply-To: <DF737E620579D411A8E400D0B77E671D750755@regdom-ex01.prod.netsol.com>
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Unique handle generation

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

--> snip <--

    Scott> Here's an idea for how handles can be used in the protocol:

    Scott> Handles should be returned when an object is created, and
    Scott> they should be added to the list of attributes associated
    Scott> with an object.  Handles should be formed with both a
    Scott> registry-unique local part and a globally-unique registry
    Scott> identifier.  Local part format should be determined by
    Scott> registry policy since these local parts must be
    Scott> registry-unique.  Registry identifiers will be assigned and
    Scott> maintained by IANA.  Handles must not be reused within a
    Scott> registry.

    Scott> Sound reasonable?

Sounds good to me. That leaves the question of who generates the local 
part: I can see three models, but I'm sure there are more:

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 ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.


Home | Date list | Subject list