ietf
[Top] [All Lists]

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

2009-10-29 14:33:13
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
  circumstances."

In Section 2.2:

  "There are several known conditions under which a PATCH request can
     fail.

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

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 conflicting modification.

As an additional comment about "Concurrent modification", this looks more appropriate as a 503 (service unavailable).

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

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