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


To: "'Robert Burbidge'" <robert.burbidge@poptel.coop>, "Ietf-Provreg (E-mail)" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Mon, 22 Apr 2002 09:48:20 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Contact Client ID Namespace Management

> -----Original Message-----
> From: Robert Burbidge [mailto:robert.burbidge@poptel.coop]
> Sent: Friday, April 19, 2002 6:01 AM
> To: Ietf-Provreg (E-mail)
> Subject: Contact Client ID Namespace Management
> 
> 
> Sources :
> draft-ietf-provreg-epp-06.txt
> draft-ietf-provreg-epp-contact-04.txt
> 
> According to the contacts specification, page 17:
> 
>   ...  
>   A <contact:id> element that contains the desired server-unique
>   identifier for the contact to be created.
>   ...
> 
> <contact:id> values are server(registry)-unique but
> client(registrar)-created. It would seem reasonable to partition the
> possible values of <contact:id> among the various contacts so 
> as to reduce
> the possibility of name collisions on creation of new 
> contacts. This would
> be a matter of server policy. One possible scheme would be to 
> allocate a 4
> character prefix to each registrar, and allow the registrar 
> to allocate
> their own 12-character suffix. Doing so would allow each 
> registrar to manage
> a subset of the complete namespace without too much overhead.

Your suggestion is based on the (possibly false) premises that the IDs
should always be client-created and that the registry-registrar model is the
only one at work.  My thought going in was that the IDs would in fact be
end-user suggested in a manner similar to the way many 'net services (think
ebay, yahoo, etc.) allow individuals to create their own user IDs, and the
client would act as agent in an attempt to create the ID with the server.
Some domain name registrars might be doing it differently, but that doesn't
mean that the protocol should be limited to supporting such a model.

> If we adopt this scheme, or a similar one, there's nothing in 
> EPP itself to
> prevent one client using identifiers from another client's 
> subset of the
> contact:id values. Would it be reasonable for a server to 
> maintain allowed
> prefixes each client, and validate incoming <contact:create> 
> commands to
> ensure that <contact:id> fields match allowed values? Again 
> this would be a
> matter of service policy?
> 
> Any thoughts on the above would be appreciated.

I'd prefer to keep this sort of policy model out of the specs completely.

-Scott-

Home | Date list | Subject list