RE: [ietf-provreg] Some EPP questions

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

> 1) epp-09, 2.9.3.4:
> 
>    In the transfer command, there is a command attribute 
> 'op=__' defined,
>    which can take values 'request', 'cancel', 'approve', 'reject',
>    'query'. In other transform commands such as 'delete', 'create', or
>    'update' no such 'op=__' attribute is defined.
> 
>    An example, where an "op=cancel" command attibute for a 
> delete request
>    is useful, could be:
> 
>    A domain object is in a pendingDelete state, and the 
> holder changes his
>    mind (he wants to keep the domain name). In this case I see no EPP
>    mechanism for the registrar to interact, i.e. cancel the delete
>    request. Also an "op=query" to figure out the state of the request
>    could be useful in such a case.
> 
>    What is the reason, why the same command attributes 
> 'op=cancel', etc.
>    are not foreseen for other transform commands?

All of the pother commands are typically processed in real time without
cross-client interaction.  A transfer requires action from a second client.
We debated the merits of allowing cancels of deletes etc., but I for one
thought such facilities out of place for commands that don't require action
from a second client.

> 2) epp-09, 3; epp-09, 2.9.3.4; epp-domain-07, 3.2.4; 
> epp-contact-07, 3.2.4
> 
>    In section 3 (epp-09), in the result codes it is described:
> 
>      Code    Response text in English
>      ___________________________________
> 
>      1000    "Command completed successfully"
>      This is the usual response code for a successfully completed
>      command that is not addressed by any other 1xxx-series response
>      code.
> 
>      1001    "Command completed successfully; action pending"
>      This response code MUST be returned when responding to a command
>      the requires offline activity before the requested action can be
>      completed.  See section 2 for a description of other processing
>      requirements.
> 
>    In the examples epp-09, 2.9.3.4; epp-domain-07, 3.2.4; 
> epp-contact-07,
>    3.2.4, (transfer command) the result code is "1000", 
> although further
>    below there is <obj:trStatus>pending</obj:trStatus>.
> 
>    What is the idea behind, that the response to the transfer 
> command is
>    labled as 'completed successfully', but on the other hand it is
>    pending?

The difference is in command processing vs. action completion.  When a
command is received and processed successfully, you get the 1000 response
code.  When something has to happen out-of-band, you get the 1001 response.
1001 means that command has been received and processed, but some action
related to the command wasn't completed before the response was sent.
 
> 3) epp-contact-07
> 
>    I am a bit confused about the meaning of the 'roid' and the
>    'contact-id'.  If I understood correctly, the only 
> difference is, that
>    the client can choose and propose a contact-id, which has to be
>    available at the server, and the roid is assigned uniquely by the
>    server.
> 
>    What is/are the reason/s that we have two identifiers for 
> almost the
>    same thing?

Some people felt that we needed a globally-unique identifier (the ROID) in
addition to the server-unique identifier (the contact-id).  There was a
lengthy debate that's documented in the mailing list archives.

> 4) epp-host-07, 3.2.5
> 
>    According to section 3.2.5, a host object can be renamed. 
> There is also
>    something about other objects that refer to the host object:
> 
>      Host name changes can have an impact on associated 
> objects that refer
>      to the host object.  A host name change SHOULD NOT 
> require additional
>      updates of associated objects to preserve existing 
> associations [...]
> 
>    It is not clear to me, what is meant here: Should a host 
> object not be
>    renamed, in case such associations remain, or are domain 
> objects with
>    associations updated implicitly together with a host name change?

When a host object is renamed, the associations to that object (such as name
server delegations) should be updated automatically as needed.

-Scott-