> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf