RE: interpretation of 'EPP idempotency'

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

Hello,

On Tue, 18 Sep 2001, Hollenbeck, Scott wrote:

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

But consider the 'contact create' example from my previous e-mail:
if I submit the same EPP command for contact creation multiple times,
the EPP server has no chance to detect the repeat and therefore must
create a fresh contact for each create command it sees, as there is
no 'unique' constraint on contacts.
So the repeated command results in repeated repository changes (multiple
contact creations); this clearly violates the idempotency definition you
quoted.

However, I agree that returning the responses of previous commands
would violate the rule of command isolation. Nevertheless, it would
greatly facilitate client error handling.

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