interpretation of 'EPP idempotency'

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

Hello,

as stated in draft-ietf-provreg-epp-04.txt, the EPP features
'protocol idempotency' to ensure 'the safety of retrying a command in
cases of response delivery failure'.
However, the implications of this feature is not specified in detail.

My interpretation is that a command should cause changes in a registry's
object repository only *once*. Repeating the very same command afterwards
should only have effect on the repository if the EPP server has not yet
processed it (e.g., because the first submission did not reach the server
due to network problems). If it has been seen and processed already (e.g.,
the command has only been re-submitted because the EPP server's response
got lost on the way back to the client), then the command should *not* be
executed again; instead, the response to the original command could simply
be repeated by the EPP server.

Question: Is the behaviour described above meant be the term 'idempotency'
in the EPP draft?


If this is *not* the case, then I wonder about the correct interpretation
and it's implications for, e.g., safe recovery from network problems.

If this *is* the case, the next question would be how to distinguish 'the
same command' from 'a different command with the same data', e.g. for
creating two contact objects for the same person. In my opinion, the only
way to accomplish this is the use of the 'client transaction id' provided
by the EPP. If it was desired to create two separate contact objects with
the same data, two different client transaction ids would have to be used.
If a contact creation was only to be repeated because of a lost server
answer, then the same client transaction id as in the initial submission
would have to be given, giving the EPP server the opportunity to detect
a repeated command.

Can the client transaction id be used for this purpose?

Regards,

_____

Thomas Corte
<thomas@knipp.de>