Re: PATCH Draft

Thanks for reviving this, James.  Here are my comments.

"The server MUST NOT create a new resource with the contents of the
request body"

Why not?  I don't see the problem.

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

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

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

Sec 2.1.1 - is this section needed?  The MUST requirements there seem
to have similar issues to the MUSTs mentioned above.  Suggest removing
the section.

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

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 IANA considerations section should register the Accept-Patch
header with the header registry defined in RFC 4229.

>   * Should it be possible to create new resources with PATCH

Sure, why not?  HTTP can indicate that with a 201 response.

>   * Should it be required to use If-Match and If-Unmodified-Since
>     on PATCH.

If that's what the client wants.  But the protocol needn't say
anything about it IMO.

Mark.

Received on Wednesday, 4 July 2007 18:07:56 UTC