RE: Command Recovery

["Bason, Chris" <cbason@verisign.com>]

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.

Chris Bason

-----Original Message-----
From: Daniel Manley [mailto:dmanley@tucows.com]
Sent: Wednesday, September 19, 2001 12:40 PM
To: Hollenbeck, Scott
Cc: ietf-provreg@cafax.se
Subject: Re: Command Recovery


yuck, enforcing unique client trid's since the begining of operations 
could get relatively costly for each transform transaction, even if 
uniqueness is only required within a registrar.

How about enforcing uniqueness within a day?  The transaction info/check 
command could require a clTRID and a date to find the object.

Dan


Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Daniel Manley [mailto:dmanley@tucows.com]
>>Sent: Wednesday, September 19, 2001 11:31 AM
>>To: ietf-provreg@cafax.se
>>Subject: Re: Command Recovery
>>
>
>
>>I guess option 1 seems like the most versatile and useful, so my 
>>preference is with 1.  Could client trids still be optional if you went 
>>ahead with number 1?  Does it even make sense to keep them optional in 
>>that case?
>>
>
>I think they can still be optional, you just lose the ability to check up
on
>one if it hasn't been provided.
>
>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.
>
><Scott/>
>