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


To: ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Fri, 9 Mar 2001 11:03:35 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Unique handle generation

>-----Original Message-----
>From: Martin Oldfield [mailto:m@mail.tc]
>Sent: Friday, March 09, 2001 11:02 AM
>To: Hollenbeck, Scott
>Cc: 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:
>
[snip]
>
>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 ?

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

Home | Date list | Subject list