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

> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-02.txt

I cannot support the following changes to the PATCH method, since
they serve no useful purpose and add complexity to HTTP.

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.

There is no reason to require that the resource already exists
(such a requirement is nonsensical in any case, since in HTTP the
resource is the temporal invariance found in mapping of URI to content,
not some file in storage).  The requirement should be that the PATCH
media type define whether an existing representation is necessary
or not, which is trivial for the server to discover when applying
the patch (it is a conflict, like any other conflict).

There is no reason to require that PATCH be subject to the same
access controls as PUT.  The methods are orthogonal and implementers
do not need to be constrained.  Yes, that is a logical implication
for use of WebDAV ACLs, but that doesn't make it a requirement
on all implementations.

"The PATCH request MUST only be used in a context which ensures
that only one user may apply a patch at a time ..." assumes a
particular application (content replication) that is not necessary
as a requirement on the protocol. In particular, this requirement
disallows the primary purpose of the original PATCH method, which
was to support collaborations among multiple authors working on
different parts of the same representation.  Yes, conflicts are
possible in such situations, but they can be handled by the process
of applying each PATCH and responding with appropriate error codes --
they do not need to be legislated out of existence by overzealous
standards.  In fact, most reliable differencing mechanisms include
content verification via context or hashing; there is no need to
require that the simple HTTP mechanisms of Etag and If-Match be used
when the client is capable of making that choice on their own, and
the server is capable of handling that choice based on the existing
HTTP/1.1 protocol and orthogonal to the definition of PATCH.
Requirements within the core protocol must be reserved for design
decisions that are necessary for interoperability, not those that
are dependent on a particular application of that protocol.

The PATCH response should not be limited to 204 -- there are many
applications that might want to know whether fuzzy matching was
used to apply the patch.  The spec should define that the response
indicates what the server did.  An improvement would be to include
any metadata in the response that was either modified or might
indicate modification, but that is better done within the body of
the response rather than mixing response metadata with that of the
patched representation.

Use of DELTAV status reporting is completely unnecessary.  The HTTP
status code is more than capable of indicating the reason for failure,
and explicit indication of what parts of the PATCH could not be
applied will have to be specific to the supported diff format in
any case.  A more reasonable mechanism would be to define a
corresponding error format for each differencing format, since
understanding of that format will be necessary for a user agent
to explain what changes (not what parts of the diff file) have
been rejected.  We can't define a universal XML response because
most diffs cannot be enclosed within XML without additional
encoding (such as base64), nor can we assume that line numbers
are meaningful to binary differencing formats, though I suppose we
could define a uniform way of counting the number of delta commands
per format and uniformly indicate errors by reference to those
numbers.

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.

There is no reason for a server to advertise support for this
method via OPTIONS *.  This is a resource-specific implementation
question and does not need any more support from OPTIONS than
is already provided for all methods.  Clients should never be
encouraged to make global requests on a server for information
that is resource-specific; servers don't work that way and all
it does is recommend that the client waste bandwidth.

Aside from what is noted above, I do think that PATCH should be
a standard part of HTTP and needs an appropriate specification.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Friday, 21 May 2004 18:45:18 UTC