Re: interpretation of 'EPP idempotency'

[Sheer El-Showk <sheer@saraf.com>]

Hi Scott,

I have to agree with Klaus here.  While I was writing my email yesterday
it did occur to me that the commands are all by nature idempotent
(because we don't alllow duplicate value in vector fields like domain
nameservers or contact statuses) I really didn't imagine that that was the
intended solution to the problem.

Not only is it potentially difficult to implement; from a design
perspective it ties your transaction management (well, I'm putting
idempotency under the broad heading of transaction management) to your
business rules and the structure of your commands.  Remember also, that in
the long run, the epp is supposed to be a generic registration protocol.
What if I define an epp extention to represent some other kind of object
which can have non-unique lists of subobjects.  In this case it would make
a difference whether I did an update once or twice.  This would put the
burden of ensuring idempotency on each extention (like renew in the
case of domain) rather than on the base protocol itself which is a much
more uniform and elegant solution.

Regards,
Sheer

On Tue, 18 Sep 2001, Klaus Malorny wrote:

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