RE: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

That works for me.

________________________________________
From: James M Snell [jasnell@gmail.com]
Sent: Friday, September 07, 2007 10:34 AM
To: Yaron Goland
Cc: Julian Reschke; Henrik Nordstrom; HTTP Working Group
Subject: Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

Yaron Goland wrote:
> [snip]
> BTW, I must admit that I still haven't seen any compelling use case for 209 as it is currently defined (e.g. with race condition protection). Just because something can be done doesn't mean it should be done. Before we put it in a standard we should make sure there is a compelling need for it.
>

Oh, absolutely.  I'm not in any particular rush to standarding 209 or
PATCH.  We need to get some implementation experience with this stuff
before we get that far.

The only reason to define 209 with race condition protection is to make
it possible for a client to verify that their changes were correctly
applied.  If that's not something we need to worry about in general,
then you're right, the race condition protections are unnecessary and
can be dropped.  Dropping it would not stop server implementations that
want to provide such protections from doing so.

So... how about this... we can just say that 209 is the equivalent to a
GET response issued immediately after the successful completion of the
request without saying anything at all about the serialization of
subsequent requests.  Does that work?

- James

>         Just my two cents,
>
>                         Yaron
>
>> -----Original Message-----
>> From: James M Snell [mailto:jasnell@gmail.com]
>> Sent: Friday, September 07, 2007 10:23 AM
>> To: Yaron Goland
>> Cc: Julian Reschke; Henrik Nordstrom; HTTP Working Group
>> Subject: Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]
>>
>>
>> Yaron Goland wrote:
>>> [snip]
>>> #1 - I don't believe that 209 with race condition protection is
>> actually necessary. Although I could easily be convinced that I'm wrong
>> if someone has a killer use case.
>> It's not necessary in every case, which is why the spec does not make
>> it
>> a MUST.  It should be possible to provide race condition protection
>> without requiring it.
>>
>>> #2 - We absolutely need the ability to return a 209 without race
>> condition guarantees. So if 209 is going to be defined with a race
>> condition prevention requirement then we can't use 209 and will need to
>> do something else.
>> Well, I'm wondering if there is some way we can signal in the 209
>> response whether or not some other change has occurred.  I know warning
>> codes are not the Cool Thing, but something along those lines would be
>> helpful to indicate that the resource has been modified before the 209
>> response was returned.
>>
>> Do you have a suggestion for what that signal could be? response
>> header?
>> warning code? something else?
>>
>> - James
>>
>
>

Received on Friday, 7 September 2007 17:41:07 UTC