- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 31 May 2000 17:10:42 -0700
- To: http-wg@hplb.hpl.hp.com
About 2 months ago, Balachander Krishnamurthy posted (on this list) a Last Call on a proposed extension to HTTP/1.1 to support "delta encoding." (More details are available in that message; see http://www.ics.uci.edu/pub/ietf/http/hypermail/2000/0074.html) Our aim was to ask the IESG to advance this to Proposed Standard status. At the time, we thought that we had resolved all of the important issues, but shortly thereafter we discovered some subtle flaws in the design, which were the result of trying too hard to use existing HTTP mechanisms (specifically, the Content-Encoding and Accept-Encoding headers). This resulted in several ambiguous situations when combining delta encoding with existing HTTP/1.1 features. Bala's Last Call is therefore retracted. Over the past two months, we've hashed out a modified design that seems to work (although, of course, that's what we originally thought about the last one). In many ways, the modified design is a lot more straightforward, but it does require the definition of some new HTTP headers. We also had to add some details to prevent improper caching of delta-encoded responses. In the process, we simplified the "Delta encoding in HTTP" draft by removing some optional features ("clustering" and "templates") to a separate document, which is not yet ready for release. These features were raising complicated issues, especially including potential security problems, and it seemed expedient to isolate them into a separate proposal. Here's an excerpt from the IETF announcement of the latest draft: Title : Delta encoding in HTTP Author(s) : J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein Filename : draft-mogul-http-delta-04.txt Pages : 45 Date : 19-May-00 Many HTTP requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called 'delta encoding.' This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mogul-http-delta-04.txt Discussion of the delta-encoding specification takes place on a separate mailing list; you can join by sending a request to <http-delta-request@pa.dec.com>. We welcome comments from people who have read the document. -Jeff
Received on Wednesday, 31 May 2000 17:16:24 UTC