At 07:40 27-10-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'PATCH Method for HTTP '
<draft-dusseault-http-patch-15.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2009-11-24. Exceptionally,
I am only writing some quick comments as I missed the deadline.
In Section 2:
"If the entire patch document cannot be successfully applied
then the server MUST fail the entire request, applying none
of the changes."
I suggest rewriting the sentence:
If the entire patch document cannot be successfully applied
then the server MUST NOT apply any of the changes and it
SHOULD return the appropriate HTTP status code as defined
in Section 2.2.
I used a "SHOULD" as the draft has:
"Other HTTP status codes can also be used under the appropriate
In Section 2.2:
"There are several known conditions under which a PATCH request can
Malformed patch document: Can be specified using a 400 (Bad Request)
when the server finds that the patch document provided by the
client was not properly formatted. The definition of badly
formatted depends on the patch document chosen, but generally if
the server finds it cannot handle the patch due to the
serialization of the patch document, this response ought to be
The wording is clear and I will probably follow the intent of the
authors of this draft. In terms of implementation, the "can be
specified using" and the "ought to be appropriate" does not clearly
spell out what status code to expect for the error condition. The
comment is applicable to the known conditions in the "Error handling"
section. I suggest being more specific about what the response
should be. For example:
Malformed patch document: When the server determines that the patch
document provided by the client is not properly formatted, it SHOULD
return a 400 (Bad Request) response. The definition of badly
formatted depends on the patch document chosen. If the server
finds it cannot handle the patch due to the serialization of the
patch document, this response is appropriate."
As an additional comment about "Conflicting modification",
"Precondition Failed" is discussed in Section 10.4.13 of RFC 2616. I
see this more of a precondition evaluated as false instead of a
As an additional comment about "Concurrent modification", this looks
more appropriate as a 503 (service unavailable).
Ietf mailing list