Re: PATCH Draft

Hi Mark,

I fail to understand the overall thrust of your proposed changes.  
Several are proposals for removing requirements   with little to gain  
from removing them.  I'd like to see a lot more benefit to removing a  
requirement before opening up what should be a simple feature to more  
variation and complexity.

Specific comments inline,

On Jul 4, 2007, at 11:07 AM, Mark Baker wrote:

>
> "The server MUST NOT create a new resource with the contents of the
> request body"
>
> Why not?  I don't see the problem.

This is to require that the server not treat the PATCH like a PUT.   
If there's a way to *apply* the patch to an empty body that might be  
fine, but the server should not save the delta algorithm as the  
resource body. If that's what the client wanted, it would do a PUT.

>
> "The server SHOULD always apply the entire patch atomically and never
> provide (e.g. in response to a GET during this operation) a
> partially-patched body"
>
> I understand the desire for atomicity, but I could see that being a
> feature as long as the fact that any partial response was tagged as
> such (using some future extension).  Suggest removal.

"features" like this cause problems.  If the client wants to  
negotiate partial responses in a separate extension, if that were  
worth while, it could be done.  If not, it makes for more solid  
interoperability to close down this variation.

>
> "If the entire delta encoding cannot be successfully applied then the
> server MUST fail the entire request, applying none of the changes"
>
> Why is this needed?  It would seem to depend upon the diff format.
> Plus I could imagine scenarios where it's undesirable (e.g. a streamed
> patch).  Suggest removal.

No.   A streamed patch or a diff format where it's desirable could  
override this requirement.  The possibility of such a format or  
extension should not induce us to leave this variation open.

>
> "Therefore, the client MUST verify that it is applying the delta
> encoding to a known entity by first acquiring the strong ETag [...]"
>
> I don't see why this is required.  Of course, if the client wants the
> guarantees provided by strong etags, it can get them.  But why does
> that matter to a protocol specification?  Suggest removal of that
> paragraph.

Why remove it?  What's the harm in making this requirement that  
clients behave properly?

> I suggest the use of 422 instead of 400 in the "malformed delta
> encoding" case of sec 2.2.2.

What's 422?

>
> Sec 2.3 seems to over specify a few things.  For example, the Allow
> response header isn't required to list "all the allowed methods" so
> there's no need for "MUST" there.  I think that all you really need in
> this section is the definition of the Accept-Patch header.

The benefit of this requirement is so that clients can count on the  
Allow header for at least this case.  What's the harm of this  
requirement?

>
> The IANA considerations section should register the Accept-Patch
> header with the header registry defined in RFC 4229.

Agreed.

thanks,
Lisa

Received on Wednesday, 4 July 2007 20:43:28 UTC