Re: Command Recovery

[Daniel Manley <dmanley@tucows.com>]

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/>
>