RE: interpretation of 'EPP idempotency'

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

> Commands are also atomic and isolated, so it doesn't really matter if the
> server receives one command sent twice or a second command that contains a
> different client ID but the same "data".  Treating each command in isolation
> and assuming that the first succeeds, in either case the second command is
> an attempt to create an object that already exists.  In both cases, the
> second attempt fails because the object will already exist as a result of
> processing the first command successfully.

Both commands may fail but they should fail in different ways.  If the
second command had a different client transaction identifer then it should
never be processed.  We shouldn't return an "object already exists" error
but some kind of "command already processed" error -- this is an important
distinction that must be made.  You can't use object uniquness to enforce
idempotency.  Idempotency has to apply to any write transaction --
insert/update/delete -- the first and last of these are by nature
idempotent, but update's aren't (and here update applies to transfer,
update, renew, etc...).  I thought that was what the client/server
transaction id was all about (see below).

>
> If the client wants to create two separate contact objects with the same
> contact data, they must do so using separate and distinct contact
> identifiers.  An attempt to create a second object using an existing
> identifier must fail.
>
> The real issue is whether or not the object exists in the repository when
> the second attempt is made.  The second attempt succeeds if the object
> doesn't exist, and it fails if it does.
>
> >Can the client transaction id be used for this purpose?
>
> Not really, because the client ID is for a _client's_ tracking purposes, and
> the server can't be assured that every ID received from any particular
> client will be unique.

From epp-04:

- An OPTIONAL <clTRID> (client transaction identifier) element that
  uniquely identifies the command to the client.


 - A <trID> (transaction identifier) element containing the transaction
  identifier assigned by the server to the command for which the
  response is being returned.  The transaction identifier is formed
  using the <clTRID> associated with the command if supplied by the
  client and a <svTRID> (server transaction identifier) that is assigned
  by and unique to the server.

  Transaction identifiers provide command-response synchronization
  integrity.  They SHOULD be logged, retained, and protected to ensure
  that both the client and the server have consistent temporal and state
  management records.


I'm not sure why there's a problem here.  If the server garauntees
per-client uniqueness of the client transaction id (it has to store them
anyway, it can just ensure they're unique), then command idempotency is
ensured (so long as the client doesn't resend the same command with a
different client transaction id).  Basically if I try to update a domain
and use a client transaction identifier, then if I never receive a server
response I can resend the update as many times as I want with the same
client transaction identifier, never worrying that the update may be
enacted twice (which would be bad if I'm adding a nameserver for instance)
because the server will only accept the first successful one.  The server
should send a response indicating that the command has already been
processed to all subsequent calls (that's why the object already exists
one doesn't really work).

Also, while this is being discussed I think the spec should make it clear
(I know the spec already uses a SHOULD not a MUST but it doesn't
distinguish between read-only and read-write commands) that client/server
transaction ids are not required (or even desirable) for
non-transactional commands such as check and info.  These are
read-only commands so command-response synchronization seems meaningless
to me.  Moreover, from a performance perspective, NSI has seen more than 1
billions checks in a month; logging each of these (ie logging the client
transaction id if provided) seems like a huge waste of resources.


>
> Does this help clear up the issue?  I can add text to the draft to help
> explain idempotency in more detail if that would help.

My undertanding is that the client/server transaction id were intended as
much for idempotency as for client audit tracking -- if not how is
idempotency to be ensured in updates?

Sheer