RE: [ietf-provreg] Some EPP questions

[Bernie Hoeneisen <bhoeneis@switch.ch>]

Hi Scott!

Thanks for your fast answers.

I have some further questions (inline).

cheers,
 Bernie

On Mon, 30 Jun 2003, Hollenbeck, Scott wrote:

> >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 attribute 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.

Whereas this seams true for the current specifications, one never knows,
what local policies and extensions to EPP will bring in the future. It
might be that these other commands (create, delete, update, ...) also
need actions from a second client for a future extension.

In the following two examples of such possible extension:

i) Lets consider a policy, where e.g. a domain update (change of delegated
   nameservers) needs the approval of the sponsoring client(s) of the
   new delegated host(s) (assuming the sponsoring client(s) of the host(s)
   differ from the sponsoring client of the domain). Such an approval
   procedure could be defined (in an extension) similarly in the transfer.

ii) Another example could be deletion of a host object, which is delegated
    nameserver also from domains of other sponsoring clients. An extension
    could define a well-defined procedure for a graceful deletion of such
    hosts by asking the approval of the other involved sponsoring
    client(s) via EPP (extension).

I don't intend to discuss now the usefulness of such possible services as
described above.

I rather want to stress out, that future extensions might need such
possibilities as provided by the 'op=__' command attribute of the transfer
command only. And if I understood the guidelines for epp extensions draft
correctly, it is not possible to add e.g. an 'op=__' command attribute to
the existing protocol commands (create, delete, update, ...), and thus
either a new protocol level extension would have to be defined, or some
child element would have to be defined with different looking syntax for
the same semantics (as the 'op=__' command attribute) in the transfer.
Please tell me if I understood things wrong.


> > 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.

Assuming the response to a transfer command is 1001 "Command completed
successfully; action pending". What would the server answer to a
transfer query command (assuming nothing concerning this transfer has
changed at server since the 1001 was sent)?


cheers,
 Bernie