[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Daniel Manley <dmanley@tucows.com>
cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <ietf-provreg@cafax.se>
From: Thomas Corte <Thomas.Corte@knipp.de>
Date: Fri, 21 Sep 2001 12:41:12 +0200 (MESZ)
In-Reply-To: <3BA9FBB8.5060206@tucows.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Command Recovery


Hello,

On Thu, 20 Sep 2001, Daniel Manley wrote:

> Thomas,
>
> I see your point but I think that it's not right to not enforce
> uniqueness and then throw an error if the queried identifier is not
> unique.  The server should probably enforce uniqueness right off the bat.

So the server would throw an error if it receives a different command
with the same trid?
This would be nice, but it has been argued that enforcing uniqueness
at the server side could involve too expensive lookup operations for
each command, especially for read-only commands which do not require the
discussed recovery.

On Thu, 20 Sep 2001, Bason, Chris wrote:

> We could avoid requiring client trid uniqueness by making
> a status command that provided additional options for the
> query. For example, if a registrar needed to perform a status
> command for a specific client trid, they could also pass
> in the operation that was being performed (e.g. CREATE, UPDATE,
> etc.) and the date that the command was transmitted.
>
> The registry would then have 4 attributes to check for the
> possible client trid being requested: registrar Id, operation,
> transaction date and client trid. If multiple rows were found
> for this combination then the status command would return a
> multi-row result set. It would then be up to the registrar to
> process the result set returned to determine whether the transaction
> they are looking for was processed.

Using the transmission date would require client and server to
agree on the *exact date* for a later status query match. Afaik,
EPP currently does not include transmission of the current date,
neither by the client nor by the server. Therefore, usage of the
date might be not feasible here.
Using the operation type (in addition to the registrar id)
to reduce the client trid namespace seems reasonable.

However, I still don't consider it a big problem to require unique
trids from the client. After all, the mechanism we are discussing
facilitates the client's recovery issues, so it shouldn't burden
the client too much to put trid uniqueness into it's responsibility.

Regards,

_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     Thomas.Corte@knipp.de              Fax: +49-231-9703-200





Home | Date list | Subject list