Re: Draft meeting minutes from the 55th IETF
"Nystrom, Magnus" <[email protected]> Mon, 25 Nov 2002 10:43:37 +0100 (W. Europe Standard Time)
| Newsgroups | gmane.ietf.sacred |
|---|---|
| Message-ID | <Pine.WNT.4.44.0211251036040.1144-100000@mnystrom-lap> |
Well, since we do not lock the credential at the server we will have a race condition regardless of whether we have an UploadResponse or not. It would be possible to add a flag to the download "download for modification" and then don't allow any other "modification downloads" until an upload happens, but I see several other problems with this approach (e.g. what happens if an upload does not happen?) and I can't see a pressing problem here since credential modifications will be quite rare and why would a user need to do them simulatenously from more than one client? To get the fresh timestamp after a successful upload clients will have to do a new download after the modification too, yes. That is the consequence of not having the UploadResponse message. -- Magnus On Thu, 21 Nov 2002, Alexey Melnikov wrote: > "Nystrom, Magnus" wrote: > > > -Upload response: Agreement not to make use of an UploadResponse > > message, but retain current text requiring clients to download (to > > ensure a fresh copy) before modifying. > > But this is a race condition? (unless you've meant "after modifying"). > > Regards, > Alexey Melnikov > __________________________________________ > R & D, ACI Worldwide/MessagingDirect > Watford, UK > > Work Phone: +44 1923 81 2877 > Home Page: http://orthanc.ab.ca/mel > > I speak for myself only, not for my employer. > __________________________________________ > > > >