RE: interpretation of 'EPP idempotency'

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

>-----Original Message-----
>From: Thomas Corte [mailto:Thomas.Corte@knipp.de]
>Sent: Monday, September 17, 2001 12:45 PM
>To: ietf-provreg@cafax.se
>Subject: interpretation of 'EPP idempotency'
>
>
>
>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?

Yes and no.  Yes in that the command should not be successfully executed a
second time (causing changes in a registry's object repository only once as
you noted), no in that the initial success response should not be returned a
second time -- the attempt to execute the same command a second time should
fail, resulting in an error return on the second attempt.

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

Commands are also atomic and isolated, so it doesn't really matter if the
server receives one command sent twice or a second command that contains a
different client ID but the same "data".  Treating each command in isolation
and assuming that the first succeeds, in either case the second command is
an attempt to create an object that already exists.  In both cases, the
second attempt fails because the object will already exist as a result of
processing the first command successfully.

If the client wants to create two separate contact objects with the same
contact data, they must do so using separate and distinct contact
identifiers.  An attempt to create a second object using an existing
identifier must fail.

The real issue is whether or not the object exists in the repository when
the second attempt is made.  The second attempt succeeds if the object
doesn't exist, and it fails if it does.

>Can the client transaction id be used for this purpose?

Not really, because the client ID is for a _client's_ tracking purposes, and
the server can't be assured that every ID received from any particular
client will be unique.

Does this help clear up the issue?  I can add text to the draft to help
explain idempotency in more detail if that would help.

<Scott/>