Re: interpretation of 'EPP idempotency'

[Daniel Manley <dmanley@tucows.com>]

Thomas,
Would this example be pulled from the operation of the .info registry? 
 They are using a older version of the spec.  In that release, the 
contact create command contains no unique identifier from the registrar, 
so multiple requests for the same contact will create duplicated in the 
registry.  In the current version of the spec, the registrar must send a 
registry-unique identifier for the contact.  If the registrar uses a 
consistent method of generating a unique id (maybe a hash of the name 
and email address?), then multiple creates of the same contact would 
fail because the id won't be unique after the first create.

Dan

Thomas Corte wrote:

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