Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 1 Jul 2005 14:28:41 +0200

* Mark Nottingham <[email-masked]> [2005-06-30 22:15]:
> The problem I'm solving is how to  reconstruct the *entire*
> state of the logical feed, not just one  partial representation
> of it; although RFC3229 could be used to do  that, it would
> require feed authors to post the entire content of  their feed
> (potentially, many megabytes). This would incur a huge  load,
> because any clients that don't support RFC3229 would have to
> GET the entire feed, leading to severe bandwidth problems.

No, that’s not necessary. For fetches which don’t supply any
RFC3229 headers, you can simply return the partial feed that you
always return.

The only problem to solve in that case is how one would go about
downloading the entire archive when one has never polled the feed
before. A simple solution that lets anyone define their own
server-side mechanism is to use a different URL given by
@rel='full-archive' (or something like that.) But this is
problematic in that there’s no defense if a non-RFC3229-compliant
client ever stumbles upon this URL.

This could be avoided by an extension element that provides an
RFC3229-compliant client with the details it needs to supply the
headers for which the server will return the entire feed. (In the
simplest form it could simply be an element that contains the
ETag itself as its content, though that feels like a kludge along
the lines of HTML’s <meta>.) Clients without RFC3229 support will
then never be able to request the entire archive. (The point is
not to defend against abuse – that’s not possible –, it is to
prevent harm from hapless users with dumb aggregators.)

Thinking about it, the cleanest way to solve this is actually not
the use of an extension element in Atom, but adding support for
this scenario to RFC3229+feed. The original RFC3229 obviously
does not assume it might be used an environment where partial
representations are, in fact, the default, rather than the
exception, as is generally the case with feeds. RFC3229+feed
could f.ex suggest that for requests that include RFC3229
headers, the server return headers with the response which inform
the client how to request the entirety of the feed – maybe
"Resource-Initial-ETag" or something like that.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jul 2005 11:41:42 -0700

> RFC3229 headers, you can simply return the partial feed that you

How do you figure that? HTTP delta encoding is a generic mechanism  
layered into HTTP; if you do a bare GET against a resource, the  
server has to return the whole representation.

> prevent harm from hapless users with dumb aggregators.)

Where does it talk about this in RFC3229? A delta-capable  
intermediary is going to be completely unaware of this, and very  
likely to return erroneous responses.

> "Resource-Initial-ETag" or something like that.

Maybe it shouldn't be called RFC3229, but what it is; a format- 
specific extension to HTTP.

Which begs the question; why do it in HTTP at all, if it's format- 
specific? Format-specific protocol extensions are generally  
considered bad practice. Why not do it in the format?

Regards,

--
Mark Nottingham     http://www.mnot.net/

---

From: "A.Pagaltzis" <[email-masked]>
Date: Tue, 5 Jul 2005 16:23:21 +0200

* Mark Nottingham <[email-masked]> [2005-07-01 20:55]:
> How do you figure that? HTTP delta encoding is a generic
> mechanism  layered into HTTP; if you do a bare GET against a
> resource, the  server has to return the whole representation.
> 
> […] 
> 
> intermediary is going to be completely unaware of this, and
> very likely to return erroneous responses.

I pored over the RFC now (I had only given it a brief look in the
context of RFC3229+feed discussion before) and see that what I
wrote is utterly bunk.

Sorry.

Regards,