W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Comments on draft-dusseault-http-patch-08, was: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 25 Jul 2007 10:55:36 +0200
Message-ID: <46A71008.1070108@gmx.de>
To: jasnell@us.ibm.com
CC: ietf-http-wg@w3.org

Find below some comments on patch-08:

Section 2.1., para. 6:

     It is RECOMMENDED that Servers provide strong ETags for all resources
     for which PATCH is supported.

Again, there's a set patch operations where the previous state of the 
resource is irrelevant, such as for "append" operations.  I think they 
should be allowed, thus this requirement is a problem.  Just state that 
strong etags can help making sure that you apply the patch to the 
version you want it   apply to, and let's leave it at that.

Section 2.1., para. 8:

     The server MUST NOT ignore any Content-* (e.g.  Content-Range)
     headers that it does not understand or implement and MUST return a
     501 (Not Implemented) response in such cases.

A MUST level requirement with a wild card Just Does Not Work.  I'm not 
even sure what this is about.  As far as I understand what we could say, 
if at all, is that entity headers sent with the request apply to the 
enclosed entity, not the resource being addressed.  Thus, for instance, 
a "Content-Language" request header in PATCH describes the natural 
language of the patch document (entity).  So what why would it be a 
problem to ignore it?  Or, rephrasing it, what do you expect the server 
to do with it?

Section 2.3., para. 2:

     Accept-Patch = "Accept-Patch" ":" #( media-range )

Need to state nature of ABNF syntax; here: borrowed from RFC2616.

Section 2.3., para. 4:

  2.3.1.  Example


  2.3.1.  Example: OPTIONS request and response for specific resource

Best regards, Julian
Received on Wednesday, 25 July 2007 08:55:46 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:14 UTC