Re: Draft meeting minutes from the 55th IETF

[Alexey Melnikov <mel@xxxxxxxxxxxxxxxxxxx>]

"Nystrom, Magnus" wrote:

> 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?)

No, I wasn't recommending this.

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

Download *after* upload makes more sense than *before* upload, for the reason
you gave.

> -- 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").

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