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.