RE: interpretation of 'EPP idempotency'

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

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

No, this can't happen.  Every contact object has an associated identifier
(see the <contact:id> element described in sections 3.1.2 and 3.2.1 of
contact-02) that MUST be unique.  In the scenario you described, the first
command will succeed.  The repeat will fail.

<Scott/>