Subject: Another revision of the I-D on "Delta encoding in HTTP"

From: Jeffrey Mogul <[email-masked]>
Date: Wed, 31 May 2000 17:10:42 -0700

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 <[email-masked]>.  We welcome comments from
people who have read the document.

-Jeff