Re: Pending Update

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

>                                                           ... The registrar
> may not serilize the update operations on an object, i.e., wait for the
> first update to be completed before requesting another. At least we are not
> making such an assumption.

Wow. That's novel.

So you want an in-protocol mechanism to ensure the temporally well-ordered
commit of asychronous writes. Because registrars don't view "hung jobs" as
edge-case bugs, subject to registrar-revocation or registry-cancellation,
but as a deferred write, and the effective state of an object the subject
of lazy evaluation semantics.

How does a registrar revoke a hung job (an asychronous write)?  

Wouldn't it be simpler to simply do a transport mapping for an existing
filesystem (over tcp) with the semantics you require?

As you observe, data bases do do this (serialize operations against object).

Putting a data base, or at least this bit of semantics, "into" the protocol
is an option. It seems simpler to observe, as Scott did, that asynchronous
exchanges might result in higher error rates if a client issues commands
without waiting to receive the responses for prior commands, rather than to
attempt to guarantee that they won't.

> Do we need more information from EPP, such as time-stamp ...

Scott and Klaus discussed roll-back last September, on-list, and I privately
discussed temporal identifier requirements with Scott on 8 Feb '01.

Eric