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


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: "'IETF Provreg'" <ietf-provreg@cafax.se>
From: Joe Abley <jabley@isc.org>
Date: Wed, 7 Apr 2004 13:24:16 -0400
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF030DFB82@vsvapostal8.vcorp.ad.vrsn.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] Unique identifiers for Contact


On 7 Apr 2004, at 13:12, Hollenbeck, Scott wrote:

>> So, just to clarify, the intention is for server-unique
>> identifiers to
>> be constructed by clients guessing repeatedly at strings which they
>> think might be unique, until one is found that doesn't
>> collide with an
>> existing identifier on the server?
>
> Of course not, the contact creation process is just like the process 
> used
> for domain and host creation.  There's a <check> command to confirm
> existence (and implementations should be lightweight enough to deal 
> with
> high volumes of <check> commands), and a <create> command to do the 
> deed
> once the existence question has been answered.

Right. So the client uses as many <check> commands as necessary in 
order to identify a server-unique string, and that string is then used 
in the <create> command. If the string identified by the <check> 
commands becomes non-unique before the <create> command is issued, 
presumably the client then has to start again.

> Then again, if you believe that the situation with domains and hosts 
> is one
> of "guessing repeatedly at strings which they think might be unique, 
> until
> one is found that doesn't collide", then the answer to your question is
> "yes".  It's not that different than registering a user name on a web 
> forum,
> or with an IM service, with an ISP, etc.

I didn't mean to sound completely flippant (only slightly flippant :-)

The difference between the two cases seems to be that in the case of 
domains and hosts, the unique identifiers are very much associated with 
the service the registry is being asked to provide. The registrar might 
be asked to create a server-unique identifier "isc.org", to be managed 
on behalf of a registrant, for example. If the server-unique identifier 
"isc.org" is not available, then the registrar can reasonably return a 
failure condition to the registrant and say "sorry, that domain is 
already taken."

In the case of contacts, the server-unique identifier is incidental to 
the reason that a registrar is interacting with the registry. The 
registrar is not about to tell the registrant "sorry, I can't register 
whatyouwanted.org because my guess at what might be a server-unique 
string for your contact object was not good enough".

It is elegant from a protocol specification perspective to have the 
server-unique identifiers in domain, host and contact objects handled 
the same way. From the point of view of practical domain registrations, 
though, it does not seem unreasonable for them to be handled 
differently.


Joe


Home | Date list | Subject list