W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Required DIFF format [was Re: PATCH Draft]

From: Lisa Dusseault <ldusseault@commerce.net>
Date: Mon, 25 Jun 2007 16:04:53 -0700
Message-Id: <C41A5218-E59C-4E2B-AA77-0C5ADAF3B3A5@commerce.net>
Cc: James M Snell <jasnell@gmail.com>, ietf-http-wg@w3.org
To: Stefan Eissing <stefan.eissing@greenbytes.de>
On Jun 25, 2007, at 1:27 PM, Stefan Eissing wrote:

>>   * Should there be a single minimum recommended diff format
>>     for binary/character based resources.  I know that this has
>>     been controversial in the past and I personally don't have
>>     an opinion on it.  I know that Lisa would prefer for there
>>     to be at least one minimum recommendation
> Personally, I think this is not helpful. PATCH cannot require  
> servers to support such a format. For every format it is trivial to  
> think of an application where it does not make sense.

That's true.  To be more clear, what I had in mind was requiring a  
MTI diff format for one particular case, that of a server that stores  
resources exactly as the client PUTs them, and the GET result is also  
byte-for-byte identical.  This is a fairly common case, particularly  
among WebDAV servers.

For resources that are stored exactly the way they appear on the  
wire, I cannot think of a case where a binary diff is going to cause  

Thus, the language I'd proposed was something like:

	In order to improve potential interoperability, servers that store  
resources unchanged
	(or can apply deltas as if resources are stored unchanged) are  
	support [FOO] as a common-denominator approach.

The problem with this is not the desirability of it -- for any server  
that wants to support PATCH and returns byte-for-byte identical  
resources, it's desirable to have a PATCH format that clients are  
likely to know.  The problem is rather that there is no binary patch  
format with a legitimately registered MIME type.

Received on Monday, 25 June 2007 23:05:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC