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