RE: interpretation of 'EPP idempotency'

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

It's apparent from Thomas' note below and Sheer's note from yesterday that I
didn't explain the concept of idempotency well enough yesterday.  It really
has nothing to do with "don't repeat commands".

It may help to start with a definition.  One of the best I've seen can be
found in a book titled "Transaction Processing: Concepts and Techniques", by
Jim Gray and Andreas Reuter (ISBN 1-55860-190-2).  On page 136 it says that
"an operation is restartable or idempotent if redoing it is safe; that is,
if redoing it an arbitrary number of times is equivalent to doing it once".
Repeated execution results in no change of state.

There are also other properties, the ACID properties, to consider in a
transaction processing environment.  ACID is an acronym for Atomicity,
Consistency, Isolation, and Durability.  I'll leave the definition of these
terms to the reader.

Now to get back to Thomas' and Sheer's questions.

EPP operations are idempotent because repeated execution of any command has
the same effect on the state of the repository as successfully completing
the command once.  In some cases this happens because the command can't be
completed more than once -- you  can't, for example, create two instances of
the same domain name in the same repository.  In other cases, this happens
because the command is structured in such a way that repeated execution
doesn't produce a state change -- for example, updating an object twice (or
more) using the same command data yields an object that looks just like it
was updated once.  Idempotency for updates is provided by ensuring that
repeated updates produce the exact same object at the end of each update.

I hope the concept is more clear now.  As I said earlier, client identifiers
have nothing to do with idempotency -- it's the structure of the commands
themselves that provide idempotency.

Lastly, Thomas' suggestion to return the results of a previous command (say
a successful <add> command) in response to a repeat of the command is a
violation of the Isolation property.  In a good transaction processing
system, each transaction has to be treated as an atomic unit of work, and
responses have to be returned to describe the result of doing that unit of
work -- not to describe the result of doing some other unit of work
performed earlier.

<Scott/>

>-----Original Message-----
>From: Thomas Corte [mailto:Thomas.Corte@knipp.de]
>Sent: Tuesday, September 18, 2001 6:04 AM
>To: Sheer El-Showk
>Cc: Hollenbeck, Scott; ietf-provreg@cafax.se
>Subject: RE: interpretation of 'EPP idempotency'
>
>
>
>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
>
>
>