W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2006

[Fwd: Re: I-D for the PATCH method]

From: Suma Potluri <suma@soe.ucsc.edu>
Date: Tue, 15 Aug 2006 16:01:09 -0700 (PDT)
Message-ID: <1282.>
To: w3c-dist-auth@w3.org

> OK, there are two ways to approach that:
> 1) either make sure that each of the patch formats indeed has it's own
> MIME type,
> 2) use generic types, and have an additional request header specify the
> type of operation.
>  From a spec writing point of view, 1) seems to be preferable to me. If
> you choose 2), you will essentially have to invent a new registry for
> types (IANA??), and have to maintain specifications for these types
> (which can be just pointers to existing specs). It's not entirely clear
> to me how this is better than registering MIME types for these formats.

Since using the content-type header for the patch format seems to be the
preferable in general, we could update the draft accordingly. The required
patch format text/normal-diff could be the used for text files and another
(optional??) patch format application/gdiff could be used for all
resources. The normal-diff format for text files seems to be preferable
over the gdiff format because it is a widely used diff format and could be
easily generated by the clients using the existing tools. We can include
the MIME type registration information in the draft for text/normal-diff
and application/gdiff patch formats.

Jim Whitehead didn't think that there would be any issue with the IPR
requirements for the gdiff patch format. But if anyone knows better, we'd
like to know.

> Binary append would be the standard use case. Text append could take
> advantage of re-encoding. Thus, I could append to a text/* resource
> without having to know it's encoding.

OK I agree that APPEND could be a special case of the PATCH method. And if
there is sufficient interest to keep the append free from the patch
formats, we could define a new MIME type such as application/entity-append
as you've suggested earlier.

Received on Tuesday, 15 August 2006 23:01:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC