To:
Thomas Corte <Thomas.Corte@knipp.de>
CC:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, ietf-provreg@cafax.se
From:
Daniel Manley <dmanley@tucows.com>
Date:
Thu, 20 Sep 2001 10:22:48 -0400
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
Subject:
Re: Command Recovery
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. Dan Thomas Corte wrote: >Hello, > >On Wed, 19 Sep 2001, Hollenbeck, Scott wrote: > >>I think a bigger question involves uniqueness: does the server have to start >>enforcing unique TRIDs for each client? Across all clients? As things are >>written right now, the clTRIDs are basically just passed-through data that >>the client can use to synchronize commands and responses, and the server >>logs them as part of the larger transaction ID. If the server doesn't >>enforce uniqueness you can get multiple hits when trying to determine >>status, which may not be helpful. If the server does enforce uniqueness, it >>becomes a bit more complex. >> > >I think the server should not have to care about the uniqueness of client >transaction ids; however, it should keep different 'transaction >id namespaces' for all clients. >If a client wants to benefit from the status command, it has to keep >his own transaction ids unique, which is a simple task. >The server may then simply report an error if it detects ambiguous >transaction ids among a client's commands. > >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 > >