ietf
[Top] [All Lists]

Re: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to Proposed Standard

2009-11-04 14:01:32

On Oct 30, 2009, at 11:01 AM, Lisa Dusseault wrote:

This is clearly a tradeoff between server flexibility and client's
being able to know what to do, so let's look at whether a client can
actually do something with the information.  In the case of a
concurrent patch, if the client knows that something else is going on
with the resource right now, it can wait a few seconds and see if the
resource has changed, then try to recalculate the patch based on the
new resource if that's appropriate.  It may be possible for the client
to resubmit the patch automatically depending on the patch format and
use case.  Even if the patch can't be resubmitted, it's possible for
the client to explain to the user what happened.

Since the requirement is a SHOULD, there is an escape clause for the
server to retain flexibility if it needs to, at the cost of having
behavior that is less predictable and manageable for the client.

Can you live with that?

On Fri, 2009-10-30 at 14:27 -0700, Nikunj R. Mehta wrote:

As I explained in my message, even a SHOULD is not a valid  
requirement. I think that no HTTP method has this kind of a  
requirement and I don't see PATCH as requiring it.

My reading of the proposed text is that it allows for modes of operation
not commonly seen in HTTP servers today (ordered pipelined operations).
Clearly, the addressing of resources on which this was to be supported
would have to be done carefully, but it's not hard to imagine ways of
doing it.

The proposed error code usage (specifying a particular code to indicate
potential conflicts between PATCH requests) is very helpful to the
client, since it allows for clearer error reports and potentially
automated recovery.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>