Re: PATCH thoughts...

> I originally thought all HTTP messages with bodies needed to
> indicate Content-Type.

It is a SHOULD.  Note that an interoperability requirement expressed
as a SHOULD is meant to allow implementers room for good reasons,
not to allow extensions of the standard to hinder future extensibility.

> I assumed that if the Content-Type header were used then that was the
> obvious place to say what diff format is being provided.  Thus PATCH
> has currently:
>
>     PATCH /file.txt HTTP/1.1
>     Host: www.example.com
>     Content-Type: application/gdiff
>     If-Match: "e0023aa4e"
>     Content-Length: 100
>
>    [body]

That is the way it was defined originally as well -- it is the only
approach consistent with the rest of HTTP.   The places where
content-type does not define the data format of the body (after the
encodings are removed) are responses to HEAD and 206.

> However, clearly RFC3229 doesn't take that approach -- some responses 
> are
> shown with bodies (implied) but with only a Content-encoding header to 
> indicate
> that there's even a body on the message.

They were working on a different problem with different optimizations
in mind.  There is no reason to follow that approach.

> This certainly routes around the MIME registration issue and may be
> preferable.  I have no strong opinions on that.

I suspect that the IESG will frown upon anything that "routes around
MIME registration".  I strongly support the use of HTTP's existing
mechanisms for self-descriptive messages.

If you don't require a specific media type, there is no reason to
require that it be a formally registered type even if that is the
ultimate goal.  The market can decide which diff formats are best
implemented for what types of resource and the types of applications
that might use PATCH.  For example, a collaboartive authoring
application will prefer fuzzy patch applications without etags,
whereas a replication utility will want minimal diff sizes with
assurance of matching content.  The protocol only needs to define
how the client describes what it wants, not what the client is
allowed to want.

VCDIFF is patented and the RF-usage disclaimer by AT&T is too
specific for my tastes.  It would be better if AT&T made the license
more broadly applicable to HTTP as an application protocol rather
than a specific version.

....Roy

Received on Monday, 3 May 2004 17:36:12 UTC