RE: EPP Schema and Example Instance Files

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Damaraju, Ayesha [mailto:ayesha.damaraju@neustar.com]
> Sent: Thursday, May 31, 2001 10:39 AM
> To: 'ietf-provreg@cafax.se'
> Subject: RE: EPP Schema and Example Instance Files
> 
> 
> 
> Scott,
> 
> Few questions/comments on new schemas...
> 
> 1. Moved the <roid> element out of the response data for 
> <create> and <info>
>    command, and now is in the <response> element as an 
> optional element.
> 
> - Please verify....This will complicate the XML validation 
> process as this
> element needs to be tested
>   explicitly for create and info. We prefer them being part 
> of create & info
> response data to simplify 
>   validations and object mappings.

My litmus test for this move was the answer to the question "is the ROID
concept common to all objects, or is it required of specific objects".  As
discussed on this list, it's common to all objects, so I though it should be
in the base protocol instead of in the object mappings.  That's why it was
moved.

Now, we could argue about where or when it should be returned.  I thought it
would be typically expected only after it was assigned (thus the <create>
response), and as part of a detailed attribute query (thus the <info>
response>).  It could just as well be returned within every response if that
makes things easier.

> 2. Added an <id> element into the <create> for creating contacts.
> 
> - Please confirm....<id> is provided by the Registrar with a <create>
> command.
>   It is a server-unique id (though generated by Registrar). 
> Server will
> reject <create> command
>   with existing <id> element.

Correct.  It must be locally unique, much as a host name or domain name must
be locally unique.

<Scott/>