To:
"'Klaus Malorny'" <Klaus.Malorny@knipp.de>
Cc:
ietf-provreg@cafax.se
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Wed, 19 Sep 2001 10:45:40 -0400
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: Command Recovery
>-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Wednesday, September 19, 2001 10:41 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se >Subject: Re: Command Recovery > > >Sorry, I used the word 'preset' that did not expressed exactly what I meant. >Of course, the client has to specify the ID and there is no default. Unique >keys of course. But here is another small disadvantage: The client has to >select a unique key, whereas it would be much easier for the server to do it >as the server knows all used keys. True, but the server doesn't know which key/identifier is one that the real live person behind the contact may find easiest to use and remember, and we do have a <check> facility in place to help determine what exists and what doesn't. Pluses and minuses both ways. I know we've been over this issue with ROIDs, handles, and the like, so I won't beat it any more. >> 1. Add a status command that checks to see if a particular client-provided >> transaction identifier has been logged as part of a successful command. >> With client TRIDs being OPTIONAL [1] this won't work if the client doesn't >> provide a TRID, but it can help if they do. Or, >> >> 2. Add client TRID information to the <info> response for an object. If we >> log the TRID of the last write operation (if one is provided), clients can >> do an <info> command, look at the client TRID, see if it's one they >> recognize, and react accordingly. >> >> Is one preferable over the other? I kind of like the second option because >> it fits into what's documented right now. Does anyone else have an opinion? >> > >Solution 1 is a more generic approach, while solution 2 is obviously easier to >implement on server side. I discussed this with Thomas and we both think that >we would prefer solution 1. OK, that's one position, thanks for weighing in. I would _really_ like to hear what others think as well since adding a new command is a fairly significant step. <Scott/>