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

Julian Reschke wrote:
> 
> Find below some comments on patch-08:
> 
> 
> Section 2.1., para. 6:
> OLD:
> 
>     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.
> 

If this were a MUST, I'd agree.  There are some extremely good reasons
why an ETag should be provided, even if there are some good cases where
they might not be useful.

> 
> Section 2.1., para. 8:
> OLD:
> 
>     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?
> 
> 

FWIW, this language was actually taken directly from RFC2616.  For
something like Content-Language, ignoring it really is not all that much
of a problem.  For Content-Range, however, ignoring the header could
cause some serious problems with the processing of the PATCH operation.

> 
> Section 2.3., para. 2:
> OLD:
> 
>     Accept-Patch = "Accept-Patch" ":" #( media-range )
> 
> Need to state nature of ABNF syntax; here: borrowed from RFC2616.
> 
> 
> Section 2.3., para. 4:
> OLD:
> 
>  2.3.1.  Example
> 
> NEW:
> 
>  2.3.1.  Example: OPTIONS request and response for specific resource
> 
> 

I'll fix these in the next draft. Thank you very much for the comments.

- James

> 
> Best regards, Julian
> 
> 
>

Received on Wednesday, 25 July 2007 16:59:45 UTC