W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

Comments on draft-dusseault-http-patch-06

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 17 Oct 2004 11:47:53 +0200
Message-ID: <41723FC9.5090207@gmx.de>
To: ietf-http-wg@w3.org

Hi,

below are some first comments on 
<http://ietf.org/internet-drafts/draft-dusseault-http-patch-06.txt>.

Best regards, Julian


C-06-01, Change to IM

I think this change goes into the wrong direction. As far as I can tell, 
there was a consensus to use the Content-Type header to identify the 
patch format. The open issue was to define one required patch format 
(with no IPR issues) and to make sure that there was a MIME type 
registered for it. This is the problem we should be solving. See also 
Roy Fielding's comment in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0086.html>:

 >> The IM header field serves no other purpose than to duplicate
what content-type is already defined to perform, and has the
added complexity of reinterpreting the meaning of the existing
error messages in HTTP that tell the client when a type is not
supported.  This is not the same problem as addressed in delta
encoding (i.e., server push replication) and does not need IM
as a solution.  Failure to define vcdiff and gdiff in the media type
registry is no excuse for adding complexity to HTTP.  I would
rather see the specification define "application/vcdiff" and
"application/gdiff" in the appendices, which it is certainly
capable of doing on behalf of the IETF, rather than allow media
type registration exemptions just because the owners had no
need for those types. <<

So in general, I think the draft needs to revert back to the -05 format. 
I'll report a few other problems with this change separately, though.


C-06-02, Section 2

<http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html#rfc.section.2>

"A set of changes for a resource is itself a document, called a delta 
encoding."

I'm confused about whether a "delta encoding" is a patch format (as 
identified in the IM header) or a particular instance of a patch request 
body See first para of section 3.1). Could you please clarify?


C-06-03, Section 2

<http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html#rfc.section.2>

"Servers SHOULD support PATCH and the vcdiff delta encoding for all 
authorable resources..."

As far as I can tell, there's an open issue with the IPR on vcdiff, as 
reported by Roy Fielding in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0086.html>:

 >> Servers SHOULD NOT support the VCDIFF format until its IP restrictions
are clarified and made available royalty-free for all uses of HTTP,
at a minimum, and not just use within HTTP/1.1 as defined in 2001. <<


C-06-04, Section 3.1, para 4

<http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html#rfc.section.3.1.p.4>

"The PATCH request MAY include a Content-Type header which is the 
content-type of the resource to which the delta encoding is to be applied."

That seems to break HTTP semantics, because the Content-Type header is 
supposed to identify the type of the request body, not the one of the 
entity it's applied to. Furthermore, the information seems to be 
completely useless unless you specifify what a server is to do in case 
of a mismatch.



C-03-08, Section 3.2.2

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

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/

-05 update: Right now it's unclear whether this is normative. If it is,
the reference to RFC3253 needs to be moved into the Normative References
section.


E-05-01, Abbreviations

...should be expanded the first time they appear in the next.


E-05-02, Security considerations

The one mentioned doesn't seem to be a *Security* consideration at all. 
It's more about correctness/robustness, isn't it?


E-06-01, mailing list

Mention the mailing list where document feedback should be sent to 
somewhere.





-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 17 October 2004 09:48:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:36 GMT