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.