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