Re: PATCH proposal

Lisa Dusseault wrote:

> 
> Just before the IETF I submitted a 5th revision of PATCH, containing 
> only minor changes:
> 
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-04.txt
> 
> Does this have any outstanding issues I'm not aware of?  I feel this is 
> now quite stable and has received wide input, and is acceptable (even if 
> not ideal) to a fairly large # of people.  A number of groups have 
> indicated they'd like to implement it (I'd like to gather more such 
> indications -- if you intend to implement PATCH, let me know).  I'd like 
> to submit it for approval as a Proposed Standard.

OK,

here are my updated comments. I think they should be addressed before 
this can go to a last-call:

C-03-02, Section 2

"This specification only defines usage of the platform-portable gdiff
[9] format identified as 'application/gdiff'."

As far as I can tell, there is no registration for "application/gdiff". 
Options:

1) do the registration in this RFC (appendix)
2) have a separate RFC for the gdiff format, including a registration
3) workaround the issue by saying that in the absence of a MIME type, 
the gdiff
format is assumed
4) ...?

(Personal preference: #1)

-04 update: I hear that Lisa is trying to get the MIME type registered. I
don't think this will work as long as the documentation only resides in a
W3C note. If PATCH is really to become an IETF standards-track document
at some point of time, normative parts of it (like the GDIFF documentation)
need to live in an acceptable place; I don't think a vendor note to the W3C
is suitable; for instance, what do we know about IP issues with it?


C-03-04, Section 3.1

"In the model defined in RFC3230 [5], the patch document is modelled
as an instance being sent to the server...."

It's unclear whether we are reusing RFC3250 or not. As far as I can tell,
this spec is independant of RCF3250, so I'm not sure what this paragraph
is trying to define.


C-03-07, Sectionb 3.2.1

"The server SHOULD provide a MD5 hash of the resource entity after the
delta was applied.  This allows the client to verify the success of
the operation.  The PATCH method MUST cause the ETag to change if the
resulting entity is not identical to the original.  If the server
supports strong ETags, the server MUST return a strong ETag for use
in future client operations.  The server SHOULD return the
Last-Modified header in any case, but the server MUST return the
Last-Modified header if ETags aren't supported."

I don't like the interdependencies here. Why not simply say, in addition
to the response headers that would be generated for a PUT request on that
resource, the server SHOULD also provide Content-MD5.

Speaking of which; it would be nice if this spec could define a standard
WebDAV property holding the content MD5, sich as DAV:getcontentmd5.


C-03-08, Section 3.2.2

2) Make this optional for servers that do not care about WebDAV.

3) Put the condition names into a different namespace, unless the WebDAV WG
agrees to adopt these names (for instance use, urn:ietf:rfc:xxxx).

3) Stick to RFC3253's terminology (the names identify conditions, not 
errors, thus

s/DAV:delta-format-unsupported/p:delta-format-supported/
s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on-resource/
s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/
s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/
S/DAV:patch-result-invalid/p:patch-result-valid/


C-03-09, Section 3.3

"OPTIONS * is not used to advertise support for PATCH because the
delta formats supported are likely to change from one resource to
another.  A server MAY include the Accept-Patch header in response to
OPTIONS *, and its value MAY be the union of known supported delta
formats."

I think that if this paragraph is removed, the spec still says the same
thing. It doesn't add anything that doesn't already follow from RFC2616.



E-03-02

"This standard defines the new method PATCH to alter a single existing
resource, in place, by applying a delta or diff file."

1) It's not a standard. It may become one later.

2) The text uses the terms "delta", "diff file" and later "patch document".
I think it would be wise to formally define *one* term for it once, and
use that one consistently throughout.


E-03-03, References

URL for [9] is missing.


E-04-01, Abstract

I think the RFC Editor prefers abstracts that do not contain links into
the references section (in particular if they're numbered and do not
have symbolic names).


E-04-02, References

The references need to be split into normative and informative. As far as
I can tell, only RFC2046 (MIME), RFC2616 (HTTP) and the GDIFF spec should
be normative.  Speaking of which, the reference to VCDIFF should be removed.


Best regards, Julian



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 20 August 2004 15:10:49 UTC