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

From: Garrett Rooney <[email-masked]>
Date: Tue, 28 Jun 2005 13:39:33 -0700

Mark Nottingham wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> 
> 
>         Title           : Feed History: Enabling Stateful Syndication
>         Author(s)       : M. Nottingham
>         Filename        : draft-nottingham-atompub-feed-history-00.txt
>         Pages           : 6
>         Date            : 2005-6-27
> 
>    This document specifies mechanisms that allow feed publishers to  give
>    hints about the nature of the feed's statefulness, and a means of
>    retrieving ^missed^ entries from a stateful feed.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
> history-00.txt

I imagine someone else has already noticed this, but there's a typo in 
the example.  The open tag uses the prefix 'fh', but the close tag uses 
'fs'.

Also, why is Stateful capitalized?  All the other parts of atom use 
lower case tag names, IIRC.

-garrett

---

From: Antone Roundy <[email-masked]>
Date: Tue, 28 Jun 2005 15:54:18 -0600

Let's say we are planning to keep the latest 15 entries in our stateful 
feed.  We publish the first entry, and have a feed with 1 entry in it.  
It has a "this" link, but no "prev" link.

Then we add an entry.  The old "this" link can't be used to point to 
the new instance of the feed, right?  Because that would violate this 
requirement:

    "The value of the "this" link relation's href attribute MUST be a URI
    indicating a permanent location that is unique to that Feed Document
    instance; i.e., the content obtained by dereferencing that URI SHOULD
    NOT change over time."

So the new feed instance has a new "this" link and perhaps a "prev" 
link pointing to the first instance.  But maybe the "prev" link could 
be omitted at this point, because the "this" link will point to a feed 
with all the information in the original feed and then some.

Now let's say someone tries to fetch the original "this" feed.  The 
draft says:

    "Note that publishers are not required to make all previous Feed
    Documents available."

This seems like a likely circumstance where the publisher might not 
want to both to continue making the original instance available.  If 
that's what they decide, then what?  Do they return a 410 (gone)?  
Presumably, some will return a 404 (not found), even though 410 would 
be better.  What should a client do if it receives a 404 or 410?  Is 
there a way for them to find the new instance?  Should there be?  
(Presumably they're subscribed to the feed from a URI different than 
the one in the "this" link, so in this case, it's probably not such a 
big deal, but read on, and you'll see where it could become an issue).

Now let's look further down the road--we have 15 entries in the feed, 
and the latest instance has it's "this" and maybe a "prev" or maybe 
not.  We add another entry.  One reasonable thing to do would be to 
continue to provide the instance with the first 15 entries and point to 
it as the "prev".  Another reasonable thing to do would be to point to 
the original single-entry instance as the "prev"--ie. the most recent 
instance which doesn't share any entries with this one.

As time goes by, the publisher could end up providing every old 
instance, or just one old instance for each 15 entries.  The latter 
would provide for much more efficient catching up on the feed state.  
But if the in between instances are dropped, clients could easily end 
up running into dead ends (410 or 404) often when trying to catch up, 
even though there is older data available at a different URI.

Perhaps the best solution would be to have no "prev" for the first 15 
instances, then point to the instance with the first fifteen entries 
from each of the next 15 instances, then point to the instance with 
entries 16-30 from the next fifteen instances, etc., so that one is 
never pointing to an instance that won't continue to be provided 
(unless, for example, you only continue to provide the most recent 10 
(for example) groups of 15 entries).

If this is to be "allowed", then one word ought to be changed in the 
draft (and I'd think that fleshing out some of these details would be 
very useful, though of course it wouldn't be normative):

    The value of the "prev" link relation's href attribute MUST be a URI
    indicating the location of the previous representation of the feed;
    i.e., the last Feed Document's "this" URI.

"THE previous representation" => "A previous representation" or 
something along the lines of "THE previous representation in the chain 
or representations".

I'm noticing now that " i.e., the last Feed Document's "this" URI." 
sounds like it's disallowing the batches-of-15 method outlined above.  
If we don't wish to disallow that, that should be changed to something 
like " i.e., a previous Feed Document's "this" URI."

Also, I just noticed that in some places, the word "representation" is 
used, and in some places "instance" is used, apparently to mean the 
same thing.  In my opinion, "instance" is better.

Antone

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jun 2005 13:25:34 -0700

This document specifies mechanisms that allow feed publishers to  
give
    hints about the nature of the feed's statefulness, and a means of
    retrieving ^missed^ entries from a stateful feed.

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at ietf.org with the word unsubscribe in the  
body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the  
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-nottingham-atompub-feed-history-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
         mailserv at ietf.org.
In the body type:
         "FILE /internet-drafts/draft-nottingham-atompub-feed- 
history-00.txt".

NOTE:   The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility.  To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command.  To decode the response(s), you will need "munpack" or
         a MIME-compliant mail reader.  Different MIME-compliant mail  
readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been split
         up into multiple messages), so check your local  
documentation on
         how to manipulate these messages.

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jun 2005 18:05:59 -0700

Hi Antone,

Thanks for the comments. This draft was admittedly rough, but I  
wanted to get an idea of people's general reactions before refining  
it too much. In particular, I'd be interested in implementors'  
reactions (e.g., aggregators, publishers).

Responses below.

> Then we add an entry.  The old "this" link can't be used to point  
> to the new instance of the feed, right?  Because that would violate  
> this requirement:
>

This is poorly worded; your 'batches of 15' scenario is what I had in  
mind. I'll work on better language for -01.

> want to both to continue making the original instance available.   
> If that's what they decide, then what?  Do they return a 410  
> (gone)?  Presumably, some will return a 404 (not found), even  
> though 410 would be better.  What should a client do if it receives  
> a 404 or 410?  Is there a way for them to find the new instance?   
> Should there be?  (Presumably they're subscribed to the feed from a  
> URI different than the one in the "this" link, so in this case,  
> it's probably not such a big deal, but read on, and you'll see  
> where it could become an issue).

I'm not sure what you're looking for; the semantics of 404 and 410  
are clearly defined by HTTP. If the server says it can't find it, or  
it's gone, the client is unable to reconstruct the full state of the  
feed, and SHOULD warn the user.

> Also, I just noticed that in some places, the word "representation"  
> is used, and in some places "instance" is used, apparently to mean  
> the same thing.  In my opinion, "instance" is better.

I'll take a look.

Thanks again!

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jun 2005 18:06:24 -0700

Thanks Garrett, I'll take this into account if I do another draft.

Cheers,

On 28/06/2005, at 1:39 PM, Garrett Rooney wrote:

> Mark Nottingham wrote:
>
>> A New Internet-Draft is available from the on-line Internet- 
>> Drafts  directories.
> I imagine someone else has already noticed this, but there's a typo  
> in the example.  The open tag uses the prefix 'fh', but the close  
> tag uses 'fs'.
>

---

From: Antone Roundy <[email-masked]>
Date: Tue, 28 Jun 2005 21:48:20 -0600

Thinking a little more about this, I'm not sure what the "this" link 
would be used for.  The "prev" link seems to be doing all the work, and 
especially assuming a "batches of 15" sort of model, the "this" link 
seems likely to end up pointing to a document that's going to disappear 
soon 14 times out of 15.

On Tuesday, June 28, 2005, at 07:05  PM, Mark Nottingham wrote:
>> big deal, but read on, and you'll see where it could become an >> issue).
>
> I'm not sure what you're looking for; the semantics of 404 and 410 are 
> clearly defined by HTTP. If the server says it can't find it, or it's 
> gone, the client is unable to reconstruct the full state of the feed, 
> and SHOULD warn the user.
>
What I'm saying is that if instance 16 of the feed points back to 
instance 15, instance 17 to instance 16, instance 18 to instance 17, 
etc., but at some point your drop all but instance 15, instance 30, 
etc., then the links to all the instances in between are going to end 
up returning 404s or 410s.  So I'd suggest that there be no 
per-instance "this" link, and that the "prev" link be updated only when 
a new batch-of-n document is created.  Doing it that way, n-1 times out 
of n, there would be overlap between the current feed and that most 
recent batch-of-n document (but that wouldn't be a big deal), but no 
overlap between any previous batch-of-n documents, and no intermediate 
documents would disappear.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jun 2005 23:10:52 -0700

You need to be able to figure out which documents you've seen before  
and which ones you haven't, so you don't recurse down the entire  
stack. Although you can come up with some heuristics to determine  
when you've seen a document before, most (if not all) of them can be  
fooled by particular sequences of entries. Remembering which ones  
you've seen (using their 'this' URI) allows you to easily figure this  
out.

On 28/06/2005, at 8:48 PM, Antone Roundy wrote:

> Thinking a little more about this, I'm not sure what the "this"  
> link would be used for.  The "prev" link seems to be doing all the  
> work, and especially assuming a "batches of 15" sort of model, the  
> "this" link seems likely to end up pointing to a document that's  
> going to disappear soon 14 times out of 15.
>

---

From: Dave Pawson <[email-masked]>
Date: Wed, 29 Jun 2005 08:32:35 +0100

>     retrieving ^missed^ entries from a stateful feed.

This tries to address my concern earlier, about an author generating
entries, with only one feed. 
  I like the basic idea of enabling differentiation between 'stable' and
other feeds.

Now I'm confused about the feed metadata and stability of feed uri's.

Any one site could now have n instances, each being a feed, the only
variant (apart from entries) being the links to previous feeds. 
If I'm to say *this* is my feed, I guess I point to the most recent...
which will change over time?

With the example of 15 entries per,

feed1 1..15
feed4 45..60

my 'feed' for my site rolls over from feed1...n as time progresses?

This smells like a kludge to me Mark. I'd *like* to have a single
url which is my feed. Using this logic presented, if I'm going to 
chunk my feed then I can't have a stable feed url?

Equally I'm not happy about a moderate blog keeping all entries
in one feed. It won't take long for the instance to become significant
in size.

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk

---

From: Danny Ayers <[email-masked]>
Date: Wed, 29 Jun 2005 10:57:17 +0200

>          Title           : Feed History: Enabling Stateful Syndication

Interesting, sounds like it could be useful. On a first read,what came to mind:

Trivial: might 1/0 be confusing compared to something clearly binary: 
true/false or yes/no, and difficult to extend: true/false/unknown

What is the Stateful nature of a feed *without* a Stateful element,
the default if you will? (Could be per-case or 'indeterminate', but I
think some comment on this would be helpful).

 If you're talking about feed reconstruction, might it not make sense
to have something like an "all" (which could appear as a minimal list
of dated URIs of entries) to avoid countless GET/interpret cycles?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 29 Jun 2005 11:36:19 +0200

What little I can add to this, not being an atom boy:

Most versioning system cannot reliably predict the URI of the next  
version. So, embedding the URI of the document inside the document  
itself, either requires document changes on submitting a new version or  
a try-and-error approach. (WebDAV deltav offers a try-and-error  
mechanism)

One could work around this by inventing a "version history" document  
which keeps the URIs of all feed versions (and the prev/next relations,  
so a reader could find out that there is a newer one also). Since the  
version history URI never changes for a feed, embedding the history URI  
inside the feed poses no challenge.

I cannot judge weather coming up with an extra document for this  
feature is overkill or not. But it would allow for easier integration  
into existing versioning mechanisms.

Best Regards, Stefan - wondering if the version history would be a feed  
of its own...

Am 28.06.2005 um 22:25 schrieb Mark Nottingham:

> i-d-announce-request at ietf.org with the word unsubscribe in the body  
> of the message.
>         "FILE  
> /internet-drafts/draft-nottingham-atompub-feed-history-00.txt".
>
>         up into multiple messages), so check your local documentation  
> on

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 29 Jun 2005 15:03:00 +0200 (CEST)

> my 'feed' for my site rolls over from feed1...n as time progresses?

I guess the answer is:
http://example.com/latest is your feed, e.g. containing the latest 10 entries
http://example.com/archive-1 through n are your "archive" feeds.

"latest" is likely to contain entries which are also "archived" in
"archive-n", but I don't see it as a problem (and it doesn't violate Atom
Feed Document rules wrt uniqueness of entries), at most I will retrieve 14
entries (if using 15 entries per "archive feed document") which I already
got from the "live" feed.

You can see "latest" as an Atom alternate for your home page (or latest
news page) and "archive-1" through "archive-n" as Atom alternates for your
"archive" pages.

What I'm wondering is, if I had "archive feeds" on a per-day basis
(instead of "N entries per archive feed", although what follows also
applies) and say I published 3 entries yesterday, 5 entries the day before
and no entry yet today:
 - http://example.net/archive/2005/06/27: 5 entries
 - http://example.net/archive/2005/06/28: 3 entries
 - http://example.net/archive/2005/06/29: doesn't exist yet
Say I'm having a "live feed" showing the latest 5 entries: it will contain
all the 3 yesterday entries and the 2 latest entries from 2005/06/27.
Could I "prev"-link to "archive/2005/06/28" or should I try to figure out
the "archive feed" containing the "previous to earliest" entry (here,
"archive/2005/06/27", but it could have been "archive/2005/06/25" if I had
only 2 entries last monday and not at all on sunday) ?
If I can just link to the "latest archive feed document", shouldn't we
then just have an "archive" link@rel in the "live feeds" (similar to the
"List-Archive" header in mail messages) and use "prev" only between
"archive feed documents" (similar to the "Next Page" link in the HTML list
archive).

-- 
Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Wed, 29 Jun 2005 07:21:58 -0600

If it's for identification rather than retrieval, maybe it could be an 
Identity Construct...except Identity Constructs got nuked in 
format-06...not necessarily dereferencable.  Another option would be to 
identify whether you need to continue by checking whether you've seen 
the "prev" link before.  Would not that be as reliable as checking the 
"this" link?

On Wednesday, June 29, 2005, at 12:10  AM, Mark Nottingham wrote:

> stack. Although you can come up with some heuristics to determine when 
> you've seen a document before, most (if not all) of them can be fooled 
> by particular sequences of entries. Remembering which ones you've seen 
> (using their 'this' URI) allows you to easily figure this out.
>
>
>> would be used for.  The "prev" link seems to be doing all the work, 
>> and especially assuming a "batches of 15" sort of model, the "this" 
>> link seems likely to end up pointing to a document that's going to 
>> disappear soon 14 times out of 15.
>>
>
> --

---

From: Dave Pawson <[email-masked]>
Date: Wed, 29 Jun 2005 14:27:55 +0100

> http://example.com/archive-1 through n are your "archive" feeds.

Which would mean that the instance at /latest keeps changing?
I need to keep swapping old ones out, new ones in, i.e. rebuilding
each time?

  I guess that's another reason it feels like a kludge.

> news page) and "archive-1" through "archive-n" as Atom alternates for your

I can see the logic of your suggestion. 
  Doesn't seem clean though?

<snip/> Other issues.

regards DaveP

---

From: Antone Roundy <[email-masked]>
Date: Wed, 29 Jun 2005 07:44:30 -0600

>   I guess that's another reason it feels like a kludge.
Replace http://example.com/latest with http://example.com/atom.xml.  Of 
course the latest document keeps changing and has to be rebuilt and 
replaced each time.  It's the feed document just like what we see 
today.  At least that's how I read what was written 
above--"http://example.com/latest" was intended as the URI to which 
you'd subscribe.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Jun 2005 09:09:40 -0700

Hi Danny,

Thanks for the comments.

> true/false or yes/no, and difficult to extend: true/false/unknown

ack

> think some comment on this would be helpful).

Yes, that's the intent; if you don't have a flag, there isn't any  
information about what it is (or isn't), and you act as you would today.

> of dated URIs of entries) to avoid countless GET/interpret cycles?

I put that forth in the original Pace <http://www.intertwingly.net/ 
wiki/pie/PaceFeedState> (see history), and it got very negative  
reviews, because it requires a lot of work to maintain, and can be a  
bandwidth hog. I'm of two minds about it.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Jun 2005 09:09:00 -0700

I think you're right... I was concerned about servers doing  
redirection, so that a client might miss the fact that it's already  
seen an archive, but as long as it uses the same identifiers to  
locate documents, it should be fine.

On 29/06/2005, at 6:21 AM, Antone Roundy wrote:

>
> If it's for identification rather than retrieval, maybe it could be  
> an Identity Construct...except Identity Constructs got nuked in  
> format-06...not necessarily dereferencable.  Another option would  
> be to identify whether you need to continue by checking whether  
> you've seen the "prev" link before.  Would not that be as reliable  
> as checking the "this" link?
>
>> You need to be able to figure out which documents you've seen  
>> before and which ones you haven't, so you don't recurse down the  
>> entire stack. Although you can come up with some heuristics to  
>> determine when you've seen a document before, most (if not all) of  
>> them can be fooled by particular sequences of entries. Remembering  
>> which ones you've seen (using their 'this' URI) allows you to  
>> easily figure this out.
>>
>>
>>> link would be used for.  The "prev" link seems to be doing all  
>>> the work, and especially assuming a "batches of 15" sort of  
>>> model, the "this" link seems likely to end up pointing to a  
>>> document that's going to disappear soon 14 times out of 15.
>>>
>>>
>>>
>>
>> --

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Jun 2005 10:09:52 -0700

Hey Mark,

A few comments after my first read through on this:

1. This appears to be addressed at solving the same problem as Bob 
Wyman's RFC3229+feed proposal 
[http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html].  Do you 
have any empiracle data similar to what Bob provides @ 
http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html that would 
indicate that your approach is a better solution to this problem?  These 
are actually not mutually exclusive solutions, they're just different 
and could be used for different scenarios -- e.g. Bob's tends to make a 
lot of sense for blog dashboard feeds like what we use within IBM to 
show all post and commenting activity within our internal blogs server 
while your mechanism would work rather well for things like Top Ten 
lists, etc.  I would just like to see a bit of a compare/contrast on the 
two approaches.

2. Is the feed state mechanism a way of paging through the current 
contents of a collection or a snapshot-in-time view of a feed?  That is...

    is it

        A) Collection has a bunch of entries.  Each feed representation 
has 15 entries and the prev link
             acts like a paging mechanism similar to what we see 
currently use in search results.  Deleting
             the first ten entries out of the collection would cause all 
of the entries in the feed to "shift backwards"
             in the feeds

         B) Each prev link is representative of how the feed looked at a 
given point in time.  E.g. the feed as it would
              have appeared at a given hour of a given day

    If it's A, then Bob's RFC3229+feed solution seems much more 
efficient. (see #1)

    If it's B, then I'm wondering why you don't just use an ETag based 
approach, e.g.

       <fs:Stateful>1</fs:Stateful>
       <fs:prev>{ETag}</fs:prev>

    This would allow clients to only ever have to deal with a single URI 
for a feed and use conditional-gets with ETag to differentiate which 
snapshot of the feed they want to get and would likely make it easier to 
remediate potential recursive reference attacks, (e.g. feed A references 
feed B which references feed C which is a blind redirect to Feed A).

3. Microsoft's RSS Lists spec uses <cf:treatAs /> to attach behavioral 
semantics to a feed.  This proposal uses <fs:Stateful /> to attach 
behavioral semantics.  It would be nice if we could come up with a 
relatively simple and standardizable way of attaching behavioral 
semantics.  For example, a standardized <treatAs /> element:

    <atomex:treatAs>stateful</atomex:treatAs>

    The value of the treatAs element would be a list of tokens with 
defined semantics.  Each token SHOULD be registered with IANA.  Unknown 
tokens would be ignored.  Incompatible tokens would be ignored with  
first-in-the-list takes precedence semantics. For example:

    <atomex:treatAs>stateful list</atomex:treatAs>

    Indicates that the feed should be treated as a list whose past 
states can be queried using the kind of mechanism you've defined.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 30 Jun 2005 02:50:23 +0200

Hi Mark,

* Mark Nottingham <[email-masked]> [2005-06-28 22:40]:
>    This document specifies mechanisms that allow feed
>    publishers to  give hints about the nature of the feed's
>    statefulness, and a means of retrieving ^missed^ entries
>    from a stateful feed.

I agree with Antone Roundy that the “this” link is unncessary
for the reasons already stated.

My first thought upon reading the draft was what I assume is
what Stefan Eissing said: I would rather have a single,
entry-less “archive hub” feed which contains “prev” links to
*all* previous instances, leading to a setup like

    http://example.com/latest
    └─> http://example.com/archive/feed/
        ├─> http://example.com/archive/feed/2005/05/
        ├─> http://example.com/archive/feed/2005/04/
        ├─> http://example.com/archive/feed/2005/03/
        ├─> http://example.com/archive/feed/2005/02/
        └─> http://example.com/archive/feed/2005/01/ 

so that it’s only necessary for the aggregator to fetch one
document to find out about all previous versions. It seems
cleaner and more robust to keep a global history list, rather
than encoding it implicitly as a chain of documents.

I don’t see anything in the draft that would preclude this use,
and as far as I can tell, aggregators which support the draft
should have no trouble handling this scenario correctly. Is it
acceptable, or did you intend to outlaw it? If yes, what is the
reasoning?

In fact, I’d probably go one step further and add a “prev”
link to each version, which points back to the archive list
feed.

    http://example.com/latest
    └─> http://example.com/archive/feed/ <────────────┐
        ├─> http://example.com/archive/feed/2005/05/ ─┤
        ├─> http://example.com/archive/feed/2005/04/ ─┤
        ├─> http://example.com/archive/feed/2005/03/ ─┤
        ├─> http://example.com/archive/feed/2005/02/ ─┤
        └─> http://example.com/archive/feed/2005/01/ ─┘

In that way, any of the files can be copied around the place,
but they never lose their association with the originals.

Again, I don’t see anything in the draft that would preclude
this use, and as far as I can tell, aggregators which support
the draft should have no trouble handling this scenario
correctly. Is it acceptable, or did you intend to outlaw it? If
yes, what is the reasoning?

Note how the archive directory feed being static makes this
painlessly possible, while it would be a pain to achive
something similar using the paginated approach with local
“prev” links (you’d need to go back and change the previously
newest old version every time a new one was added). It would
in fact require a “prev” link to what is actually the “next”
page.

Funnily enough, I don’t see anything in the draft that would
preclude this counterintuitive use of the “prev” link to point
to the “next” version, and as far as I can tell, aggregators
which support the draft [etc]?

Overall, I must say this feels kludgy to me, any way I turn it.
I’d much rather have a single archive feed containing all
entries, and use RFC3229+feed to return partial versions of it;
as far as I can tell, this is a use case which your draft does
*NOT* allow. Is that so?

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

---

From: Antone Roundy <[email-masked]>
Date: Wed, 29 Jun 2005 19:54:16 -0600

On Wednesday, June 29, 2005, at 06:50  PM, A. Pagaltzis wrote:
> *all* previous instances
For an active feed, that document could easily grow till it was larger 
than many feed instances.  I prefer the chain of instances method.

> , leading to a setup like
>
I don't quite get what the "hub feed" would look like.  Could you show 
us some XML?

> should have no trouble handling this scenario correctly.
The draft doesn't explicitly say that a feed can only contain one 
"prev" link, but I find it hard to read "a" to mean "one or more" in 
'and optionally a Link element with the relation "prev"'.

> correctly.
...unless they expected only to find one "prev" link per document.

> newest old version every time a new one was added).
I don't see why this would be any more difficult.  The paginated 
approach could easily use static documents that never need to be 
updated, as I described earlier.  I'll re-explain at the end of this 
email.

> It would in fact require a “prev” link to what is actually the “next”
> page.
>
> to the “next” version
Could you explain what you mean by that?

> entries, and use RFC3229+feed to return partial versions of it;
That might be good for those who can support it, but many people won't 
be able to.  On the other hand, if that single feed grows to where it's 
hundreds of MB, it could cause real problems if someone requests the 
whole thing or a large portion of it.

Getting back to how to use static documents for a chain of instances, 
that could easily be done as follows. The following assumes that the 
current feed document and the archive documents will each contain 15 
entries.

The first 15 instances of the feed document do not contain a "prev" 
link (assuming one entry is added each time).

When the 16th entry is added, a static document is created containing 
the first 15 entries, and a "prev" link pointing to it is added to the 
current feed document. This link remains unchanged until the 31st entry 
is added.

When the 31st entry is added, another static document is created 
containing the 16th through 30th entries. It has a prev link pointing 
to the first static document. The current feed document's prev link is 
updated to point to the second static document, and it continues to 
point to the second static document until the 46th entry is added.

When the 46th entry is added, a third static document is created 
containing the 31st through 45th entries, etc.

If you want to reduce the number of requests required to get the entire 
history (which I don't imagine would happen often enough that it would 
necessary be worth bothering), you could put more entries into each 
static document.  If you didn't correspondingly increase the number of 
entries in the current feed document, you'd have to update the most 
recent static document a number of times rather than only outputting it 
once as described above, but even that would only require multiple 
updates to the most recent static document at any time.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 30 Jun 2005 13:01:55 +1000

On 30/6/05 11:54 AM, "Antone Roundy" <[email-masked]> wrote:

>> I¹d much rather have a single archive feed containing all

also, how can RFC3229+feed provide subsets where one end isn't tied to the
most recent entry?

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 30 Jun 2005 13:00:02 +1000

> I don't quite get what the "hub feed" would look like.  Could you show

I think something like this:

<feed>
    ...
    <title>archives hub for x</title>
    <link href="http://example.com/archive/feed/2005/05/"
          type="application/atom+xml"
          rel="prev" />
    <link href="http://example.com/archive/feed/2005/04/"
          type="application/atom+xml"
          rel="prev" />
    <link href="http://example.com/archive/feed/2005/03/"
          type="application/atom+xml"
          rel="prev" />
    <link href="http://example.com/archive/feed/2005/02/"
          type="application/atom+xml"
          rel="prev" />
    <!-- no entries -->
</feed>

... although ... now that I've typed that out ... the semantics of "prev"
are borked.

So maybe something more like this would make better sense

<feed>
    ...
    <entry>
        <id .../>
        <link href="http://example.com/archive/feed/2005/05/"
            type="application/atom+xml"/>
        <title>Archive for 2005/05</title>
        <summary>27 posts</summary>
    </entry>
</feed>

That is: "here is a resource representation providing a list of entries
which are representative of some other resources, not necessarily in
text/html format"

e.

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 30 Jun 2005 12:03:54 +0200 (CEST)

> containing the 31st through 45th entries, etc.

However, there should then be a "this" link in the "live" feed, otherwise
I'll have to retrieve (as a reader/aggregator) the "prev" feed each 15
entries:

Say I retrieved the feed when it was 15-entries long. When the 16th entry
is added and the first static document created, the "live" feed is added a
"prev" link, pointing to a document I never retrieved, so I guess I might
have missed entries and retrieve it. I end up retrieving back the 15
entries I already know of.
When the 31st entry is added, the feed's "prev" link is changed to
reference the new 16th-to-31st archive feed. This is an URI I never
dereferenced, so I guess I might have missed some entries and then
dereference the URI and retrieve the archive feed. If I had retrieved the
feed when it was 30-entries long, I end up retrieving back the 16th to
31st entries I already know of.

One could argue that I don't need to retrieve the archive feed as the live
feed already contains 14 entries (2nd to 15th, or 17th to 30th) I already
retrieved, using atom:updated and atom:id to notive them.
Well, nothing precludes an entry to be "pushed to front" even if its
atom:updated hasn't changed, so the entry following such a "puished to
front" entry could be one I never saw and I might have missed it.
And actually, this doesn't otherwise change the problem, which would still
arise if I retrieve the "live" feed when, say, it was 15-entries long and
15 entries later: I never saw the "prev" archive feed or any of the 15
entries in the "live" feed (so I can't conclude anything based on
atom:id+atom:updated), I then retrieve the "-prev" linked archive feed and
end up retrieving 15 entries I already know of, because it happens than I
actually didn't miss any entry between my two "live" feed retrievals...

So we need a mean to either identify the *next* "prev" link (a "this" or
"permalink" link in the "live" feed (no need to have one in "archive"
feeds, as already said on the list), which means it must be predictable),
or something to tell us we didn't missed entries, such as the atom:updated
of the "prev"-linked archive feed (is atom:updated enough?).

We'll end up with the "live" feed being either:
<feed xmlns="..." xmlns:fs="...">
  <link rel="archive" href="http://example.com/2005/05/" />
  <!-- I didn't use a link construct as the document not yet exists) -->
  <fs:predicted-archive-uri>
        http://example.com/2005/06/
  </fs:predicted-archive-uri>
  ...
</feed>

or

<feed xmlns="..." xmlns:fs="...">
  <!-- I used an "extension attribute", even if it's not clearly
       defined by the Atom Syndication Format -->
  <link rel="prev" href="http://example.com/2005/05/"
        fs:updated="2005-05-31T23:59:59" />
  ...
</feed>

One advantage of the latter is that you don't rely on URIs as identifiers
for the feed archive documents and they can be moved/split/merged without
readers and aggregators being then implicitly told to retrieve back the
whole archives (if you change URIs, they'll think they missed entries...).

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jun 2005 13:04:58 -0700

Hi James,

On 29/06/2005, at 10:09 AM, James M Snell wrote:
> Wyman's RFC3229+feed proposal [http://bobwyman.pubsub.com/main/ 
> 2004/09/using_rfc3229_w.html].  Do you have any empiracle data  
> similar to what Bob provides @ http://bobwyman.pubsub.com/main/ 
> 2004/10/massive_bandwid.html that would indicate that your approach  
> is a better solution to this problem?  These are actually not  
> mutually exclusive solutions, they're just different and could be  
> used for different scenarios -- e.g. Bob's tends to make a lot of  
> sense for blog dashboard feeds like what we use within IBM to show  
> all post and commenting activity within our internal blogs server  
> lists, etc.  I would just like to see a bit of a compare/contrast  
> on the two approaches.

It's orthoganal to RFC3229. 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.

To give a concrete example, Dave Winer would have to post one RSS  
file containing every entry he's made in Scripting News for the past  
10+ years to use RFC3229 to meet the same goal; with this proposal,  
he'd just have to add a 'prev' to each archived feed (assuming he has  
archives around, which if he doesn't, I imagine he could reconstruct).

>        A) Collection has a bunch of entries.  Each feed  
> representation has 15 entries and the prev link
>             the first ten entries out of the collection would cause  
> all of the entries in the feed to "shift backwards"
>             in the feeds
>
>         B) Each prev link is representative of how the feed looked  
> at a given point in time.  E.g. the feed as it would
>    If it's B, then I'm wondering why you don't just use an ETag  
> based approach, e.g.
>
>    This would allow clients to only ever have to deal with a single  
> URI for a feed and use conditional-gets with ETag to differentiate  
> which snapshot of the feed they want to get and would likely make  
> it easier to remediate potential recursive reference attacks, (e.g.  
> feed A references feed B which references feed C which is a blind  
> redirect to Feed A).

This proposal doesn't handle deletion or other aspects of identity in  
feeds; I tried to introduce language like that earlier in Atom  
itself, but we failed to gain consensus around it.

How does an ETag help you locate a previous feed to reconstruct  
state? Even if it could, I'm not sure intermingling HTTP protocol  
details with application semantics; although there's nothing to  
prevent this theoretically, in many implementations, it might be  
problematic to predict what the ETag is.

> 3. Microsoft's RSS Lists spec uses <cf:treatAs /> to attach  
> behavioral semantics to a feed.  This proposal uses <fs:Stateful />  
> to attach behavioral semantics.  It would be nice if we could come  
> up with a relatively simple and standardizable way of attaching  
> behavioral semantics.  For example, a standardized <treatAs />  
> element:
>
> defined semantics.  Each token SHOULD be registered with IANA.   
> Unknown tokens would be ignored.  Incompatible tokens would be  
> ignored with  first-in-the-list takes precedence semantics. For  
> example:
>

That seems like an awfully heavyweight solution. What does defining  
the container and an IANA registry add?

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Jun 2005 13:41:04 -0700

Mark Nottingham wrote:

>> lists, etc.  I would just like to see a bit of a compare/contrast  on 
>> the two approaches.
>
>
At times we do get spolied by the ability to dynamically generate 
responses don't we ;-) You're obviously correct when it comes to 
statically generated content - RFC3229+feed does not provide a workable 
solution in that case.

>> which snapshot of the feed they want to get and would likely make  it 
>> easier to remediate potential recursive reference attacks, (e.g.  
It's not so much using ETag to reconstruct state as much as it is to 
view access previous views of the feed.  Btw, I threw this out for 
discussions sake and not because I think it's the "right" solution.  I'm 
not particularly in love with it myself.

>> behavioral semantics.  For example, a standardized <treatAs />  element:
>>
The value is that I would really like to see a common and consistent way 
of attaching behavioral semantics to the feed rather than each 
individual vendor / spec defining their own app and impl specific 
methods.  It could be done without IANA support, of course, but it's 
just annoying to see relatively similar tasks done in completely 
different ways.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jun 2005 13:46:46 -0700

On 30/06/2005, at 1:41 PM, James M Snell wrote:

> The value is that I would really like to see a common and  
> consistent way of attaching behavioral semantics to the feed rather  
> than each individual vendor / spec defining their own app and impl  
> specific methods.  It could be done without IANA support, of  
> course, but it's just annoying to see relatively similar tasks done  
> in completely different ways.

I totally agree that we should have neutral, non-vendor-specific  
semantics defined. I just don't see how having this container  
defined, along with the IANA registry, helps; if it was the intent of  
the WG to forbid all vendor-specific mechanisms, we should have  
disallowed all extensions except for those that are in an IANA  
registry (for example).

That's an extreme, of course, but it points out that Atom -- and RSS,  
for that matter -- is still in the period of its lifetime where  
vendors and individuals have to experiment to figure out what's  
valuable, and let the market sort out what becomes commonly deployed.  
It's not pretty, but it works pretty well in the long run.

Cheers,

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Jun 2005 14:16:54 -0700

Mark Nottingham wrote:

>> The value is that I would really like to see a common and  consistent 
>> way of attaching behavioral semantics to the feed rather  than each 
<Sigh> Why can't technology work well AND be pretty. 

- James