Subject: WordPress extension supports RFC3229 Delta Encoding for RSS

From: "Bob Wyman" <[email-masked]>
Date: Tue, 14 Sep 2004 19:39:21 -0400

James Robinson reports on his blog that he has implemented an
extension to WordPress to support RFC3229 delta encoding. The code is
surprisingly simple... 
	See: http://www.robinsonhouse.com/2004/09/14/rss-and-delta-encoding/
      I've asked that he extend his support to include the "feed" IM method
that I describe at: 
http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html
	If he, or someone else, does that, then it would be a short step
from there to Sam Ruby's suggestion of having delta encoding turned on by
default -- and we can do it with minimal modification to existing standards!
Hopefully, Robinson's code will convince people of how easy delta encoding
can be for feed-like resources.

	James points out that there is apparently a bug in Apache that
prevents setting a status code of "226 IM Used" and has asked for people to
vote for this bug in Apache's Bugzilla. Given that implementation of delta
encoding could do a great deal towards making Atom more useable on the web,
I would encourage everyone who can to go to the Apache site and vote for
this bug...
	GoTo: http://issues.apache.org/bugzilla/show_bug.cgi?id=31228
	News Aggregator developers should also be encouraged to ensure that
they support the 226 status code and strongly consider providing support for
RFC3229. Doing this will drastically reduce the bandwidth requirements of
Atom syndication.

		bob wyman

---

From: patrick mcmanus <[email-masked]>
Date: Wed, 15 Sep 2004 09:34:06 -0400

On Tue, 2004-09-14 at 19:39, Bob Wyman wrote:
> default --

 I've read this a couple of times, and I think a 'default' deployment
would really be a mistake.

Let me first define what I think you mean by default.. maybe we're
talking about different things. I think you mean an HTTP/1.1 origin
server receiving a 1.1 level request that contains a If-None-Match
request header but does not contain an A-IM request header... this
server would generate a delta against one of the entities listed in the
I-N-M header and use that for it's response. The response would be
labeled with a response code 200, probably contain a IM response header,
and include Vary: If-None-Match too. Please adjust my interpretation
where needed.

This is proposed to work because rss clients implicitly already know how
to re-assemble deltas even if they don't know rfc 3229 and therefore
know enough to stick A-IM in the request.

There are at least two things that will cause you problems:
  1] HTTP/1.0 caches in line
  2] Conservative implementations of 'vary'.

1] Anytime there is an HTTP/1.0 cache in line vary doesn't work. There
is no way for the origin server to know if a 1.0 cache is inline. (and
indeed, it may come into play on a later cache hit). Preventing this
problem is a fundamental reason why rfc 3229 uses the response code 226
instead of 200.. but you can't send 226 to clients that didn't send
A-IM, many of them will throw up their hands in confusion.

2] There are lots of conservative implementations of vary that will
essentially turn these responses into uncachable responses. This
treatment of vary keeps the caches compliant (if unhelpful) and saves
them the work of implementing a tricky and seldom used feature. Creating
uncachable data is probably not a good side effect of a bandwidth-saving
proposal ;)

I'd also argue this violates the well understood semantics of HTTP.
If-None-Match/304 is well understood as a binary hit/miss mechanism. Two
responses of the same etag should be able to be decoded _within the http
layer_ to generate the same entity. That's what the etag promises after
all. If a decode process needs to be done to calculate that entity (such
as gzip, delta, et al) it should be done within the HTTP layer.
Otherwise there is no way to verify coherency at the HTTP layer. rfc
3229 solves that, but you've got to play along with the A-IM bits.
Changing the meaning of something as well understood as AIM/304/etag is
bound to cause unanticipated fits.

by the way, I'm really excited about delta encoding and RSS - it makes
lots of sense. I started reading this thread when someone forwarded me
the bit about delta-encoding and the apache module contest (are details
of that forthcoming, btw?).. 

-Patrick

---

From: Eric Scheid <[email-masked]>
Date: Thu, 16 Sep 2004 01:19:06 +1000

On 15/9/04 11:34 PM, "patrick mcmanus" <[email-masked]> wrote:

> [...]
> all.

+1.

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 15 Sep 2004 15:21:36 -0400

James Robinson has updated his RFC3229 extension for WordPress to
support the "feed" instance-manipulation method that I described on my
blog.[1] To see James' comments and get his code, go to:
http://www.robinsonhouse.com/2004/09/15/rfc3229-with-feeds-for-wordpress/

	If Microsoft had been using WordPress with this extension, I think
they would not have experienced the problems that they recent had...

		bob wyman

[1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html