Re: I-D ACTION:draft-dusseault-http-patch-05.txt

Hi Lisa,

Just a few notes (mostly nits) from reading -05. I haven't tracked the 
entire PATCH discussion, so feel free to tell me that a subject has 
already been discussed if I need to do more homework.

* 3.1 - "The target resource's content type MUST be one to which the 
patch format applies." The applicability of a patch format isn't 
well-defined in this document. I'd suggest either not making this a 
RFC2119-level requirement, or parenthetically clarifying what's meant 
by "applies;" for example, "... format applies (e.g., some textual 
patch formats can't operate upon binary resources)"

* 3.1 "A cache MAY mark the resource identified in the Request-URI as 
stale if it sees a successful response to the PATCH request." First of 
all, a minor nit; I think this should be "A cache MAY mark entities 
associated with the resource identified..." Secondly, I'm uncomfortable 
with the MAY here; is there any reason it isn't a stronger requirement, 
if the cache is PATCH-aware? RFC2616 section 13.10 sets the bar at 
SHOULD.

* How does PATCH interact with server-driven content negotiation? I 
might expect that if I PATCH something with an Accept header that was 
sufficiently specific, I'd be patching that particular representation.

* 3.2.1 "The server SHOULD provide a MD5 hash of the resource" -> "The 
server SHOULD send the Content-MD5 header in responses to PATCH." (or, 
is this intentionally vague?)

* 3.2.2 "delta-format-unsupported: Used with 403 Forbidden status 
code." Wouldn't 415 Unsupported Media Type be more appropriate, given 
the current design?

* 3.3 "OPTIONS * is not used to advertise support for PATCH because the 
patch formats supported..." From context, it seems that you want to say 
that OPTIONS * shouldn't return an Accept-Patch header. However, the 
text above could be read as saying that OPTIONS * shouldn't return 
PATCH in the Allow header. I'd suggest something like "OPTIONS * is not 
used to advertise support for patch formats, because those supported 
are likely to change from one resource to another."

* PATCH's safety and idempotency should be clearly specified.

* It might be helpful to point out in the introduction that whereas 
PATCH is used to modify the body, PROPPATCH can be already used to 
modify headers and other metadata (this gives a nice symmetry between 
PATCH and delta encoding for the body, and then PROPPATCH and updates 
of headers in the caching model).

Cheers,


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 2 September 2004 16:33:12 UTC