Subject: RE: [ietf-provreg] Some EPP questions

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 2 Jul 2003 15:11:45 +0200 (CEST)

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 7 Jul 2003 09:56:26 -0400

> If the response code to the transfer command was 1000, the <trStatus>
> element of the response to the following transfer query 
> command contains
> 'pending' (as in the response to the transfer command itself).
> 
> But what does the <trStatus> contain in the response to the transfer
> query command, if the response code to the transfer command itself was
> 1001?

I believe that the appropriate response for an accepted transfer command
that requires confirmation or cross-client approval is 1001 because the
command has been accepted, but the actual transfer action is pending.  A
transfer that can be completed right away should be noted with a 1000
response.  A successful query should always return a 1000 response.

The <trStatus> response to the transfer query depends on the current state
of the transfer.  If a 1001 response was sent for the transfer command, the
transfer didn't happen right away.  Initially the value should be "pending".
From there the value of <trStatus> depends on what happens between the time
the transfer was requested and the time the query is made.  It might be
"pending" if nothing has happened, but it could be any of the other values
if a client or the server have done something (such as approved, rejected,
or cancelled the request) since the original transfer command was processed.

> And one further question, what does the <trStatus> contain in the
> response to the transfer command itself, if its response code is 1001?

Now that I think about it, it should be "pending" if a 1001 response is
returned.

I think I see what's prompting your questions: the domain and core drafts
include an example with a 1000 response and a "pending" <trStatus>; those
should be fixed to return a 1001 response or a different status value.  I'd
prefer to change the response code when I do the 48-hour edits.

-Scott-