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.
> __________________________________________
>
>
>
>