Re: interpretation of 'EPP idempotency'

[Klaus Malorny <Klaus.Malorny@knipp.de>]

"Hollenbeck, Scott" wrote:
> 

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


Hi Scott,

your solution surely works, but, from a design perspective, this is IMHO a bad
solution. Each request has to take care for itself not to violate the
idempotency constraint. E.g. the contact create command e.g. requires to
specify a <contact:id> to solve the idempotency problem, but the renew command
requires something quite different, namely the current expiration date, which
does not make any sense for the semantics of the command itself. There is no
uniform handling in the protocol. There is no chance to write software that
deals with a communication interruption without knowing in detail what a
specific request does and what the possible answers of the server are. This is
just a pain. There is no way to ask the server "did you perform the command I
sent to you?". Even if the replay of a command does not change the state of
the server, the client will get different answers. And these answers are
indistinguishable. What does a "domain exists" message really mean to the
client? The client cannot determine whether the domain was created by himself
or by another instance running in parallel that accidentically wants to create
the very same domain? How should the client determine whether to create a
mirror object in the own database? The only solution would be that the client
issues a inquire command and compares the data returned with the own data,
e.g. compare all the contacts and hosts. Even in this case it is not
guaranteed that the client's database becomes corrupted.

Instead of building upon idempotency constraints which affect the design of
each command, it would be better to have a separate layer that deals with
problems that appear in a client-server architecture. The way we do it in the
CORE SRS Protocol is one solution, it is quite simple and it works.


Klaus Malorny


___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0