RE: interpretation of 'EPP idempotency'

[Thomas Corte <Thomas.Corte@knipp.de>]

Hello,

On Mon, 17 Sep 2001, Sheer El-Showk wrote:

> Both commands may fail but they should fail in different ways.  If the
> second command had a different client transaction identifer then it should
> never be processed.  We shouldn't return an "object already exists" error
> but some kind of "command already processed" error -- this is an important
> distinction that must be made.  You can't use object uniquness to enforce
> idempotency.  Idempotency has to apply to any write transaction --
> insert/update/delete -- the first and last of these are by nature
> idempotent, but update's aren't (and here update applies to transfer,
> update, renew, etc...).  I thought that was what the client/server
> transaction id was all about (see below).

In my opinion, idempotency can not be forced without use of the client
transaction id in some cases. For example, it is perfectly legal to
create two contacts with the very same data (Name/Address etc.).
If I resubmit a contact creation command due to a lost server response,
the EPP server can not decide whether it should create a new contact
(and return a new ROID) or not - idempotency can't be guaranteed via the
proposed 'object already exists' method.

There is no real harm done in this case, because it would only result in
the creation of a redundant contact (which ROID is lost and would never be
used). But in principle, this violates protocol idempotency, because the
repeated command changes the repository while it shouldn't. Only the usage
of the client trid (or something similar) can solve the problem - using
the same trid indicates 'the same command', using a different trid
indicates 'a different command'. Of course, the client would have to take
care of the appropriate client trids.

> I'm not sure why there's a problem here.  If the server garauntees
> per-client uniqueness of the client transaction id (it has to store them
> anyway, it can just ensure they're unique), then command idempotency is
> ensured (so long as the client doesn't resend the same command with a
> different client transaction id).  Basically if I try to update a domain
> and use a client transaction identifier, then if I never receive a server
> response I can resend the update as many times as I want with the same
> client transaction identifier, never worrying that the update may be
> enacted twice (which would be bad if I'm adding a nameserver for instance)
> because the server will only accept the first successful one.  The server
> should send a response indicating that the command has already been
> processed to all subsequent calls (that's why the object already exists
> one doesn't really work).

I think that idempotency should give clients the possibility for a uniform
error handling. The client should *not* need to handle the
outcome of repeated command itself. To shift this into a different
'protocol layer', the described client trid method could be used.

Moreover, IMHO the EPP server should just repeat the response of the first
command issue whenever it encounters a repeat (same client trid); then
the clients would not have to worry about this issue at all.

Regards,

_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     Thomas.Corte@knipp.de              Fax: +49-231-9703-200