RE: interpretation of 'EPP idempotency'

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

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

Creation and renewal are fundamentally different operations, even at the
database level.  Both, however, involve comparing the current state of an
object to the desired state of an object and then doing something if it's
possible to produce the desired state.  Given that different attributes
define the state of an object and the operations that may be performed on
the object, I don't see the problem with commands requiring different
attributes to perform the needed state comparison.  In the case of renewal
you're moving the current expiration date into the future, changing the
state of the object as a result of a successful operation.  Using this
attribute as an indicator of the current state prior to attempting to
produce a new state is reasonable.  Likewise, using a different attribute (a
unique identifier) to determine if an object can be created is also
reasonable.

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

I disagree.  If a client is unsure if any command was processed
successfully, they can try it again.  Doing so is guaranteed to not have
damaging results.  If they get back a "succeeded" response, they can update
their own records and move on.  If they get back a "failed" response, they
look into the third and fourth error code digits to determine the exact
failure, and resynch/roll back/whatever accordingly.  If you're suggesting
that a server shouldn't provide different types of error responses (and thus
that a client shouldn't be expected to understand different failure modes),
the alternative is to be more generic.  Software can be written to provide a
layer of abstraction for a client that wants less detail, but at some point
the detail needs to exist.

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

No, the responses are quite distinguishable.  In one case it may be
"success", and in the other it may be "failure", and each is clearly
identified by response code and a unique server-assigned transaction
identifier.  This is as it should be because each response is tied directly
to a very specific command, one of which succeeded and one of which failed.
A good OLTP system should NOT provide a response to a command that describes
the result of processing some other command.

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

The message received back shouldn't first be interpreted as "domain exists"
in the case of a repeated domain create command failure -- the primary
message is _"command failed"_, and the "domain exists" part is extra
information that helps to explain why the command failed.  If the command
fails, the client shouldn't create or keep it's own copy of the data.  If a
response is lost, I think it's very reasonable for the client to issue a
separate, atomic inquiry, and to ensure data consistency using the results
of the query.  If they prefer to blindly repeat a command, that command MUST
be treated as a distinct command in it's own right, it must succeed or fail
in it's own right, and results reported must describe the success or failure
of this isolated operation.  Doing otherwise is bad OLTP design.

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

There's nothing stopping anyone from defining an additional processing layer
to provide whatever feature you think is lacking.  Transport and security
layers are already described, and folks are designing and implementing SDKs
to provide additional abstract layers to deal with connection management,
error handling, etc.

<Scott/>