To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
CC:
"Bason, Chris" <cbason@verisign.com>, ietf-provreg@cafax.se
From:
Daniel Manley <dmanley@tucows.com>
Date:
Thu, 20 Sep 2001 12:41:18 -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
sounds good. Dan Hollenbeck, Scott wrote: >>-----Original Message----- >>From: Bason, Chris [mailto:cbason@verisign.com] >>Sent: Thursday, September 20, 2001 9:59 AM >>To: ietf-provreg@cafax.se >>Subject: RE: Command Recovery >> >> >> >>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. >> > >This seems like a reasonable way to provide the functionality without >significantly burdening either server or client. Does anyone disagree? > ><Scott/> >