Subject: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Oct 2006 11:13:06 -0700

I've only had positive comments about -07 so far, so I've recommended  
it for publication as a Proposed Standard to the IESG.

As part of that process, I'm issuing an informal, pseudo-WG Last Call  
on the document to capture any remaining feedback. In particular,

* What do people think about putting this document on the Standards  
Track?

* Do you have an implementation available, in progress, planned, etc.?

http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/

Please provide feedback by October 18th.

Cheers,

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

---

From: James M Snell <[email-masked]>
Date: Wed, 04 Oct 2006 12:45:54 -0700

Are you aware of Atom feeds that are currently implementing this version
of the draft?  I'd like to do some interop testing.

- James

Mark Nottingham wrote:
> 
> I've only had positive comments about -07 so far, so I've recommended it
> for publication as a Proposed Standard to the IESG.
> 
> As part of that process, I'm issuing an informal, pseudo-WG Last Call on
> the document to capture any remaining feedback. In particular,
> 
> * What do people think about putting this document on the Standards Track?
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Oct 2006 21:47:49 -0700

My blog <http://www.mnot.net/blog/> has conformant RSS and Atom  
archived feeds.
    <http://www.mnot.net/blog/index.rdf>
   <http://www.mnot.net/blog/index.atom>
I also have a demonstration implementation of a client that will  
reconstruct archived feeds;
   <http://www.mnot.net/rss/history/feed_history.py>

Others? I know paging is used informally a lot in other situations/ 
specs.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Oct 2006 16:16:38 +0200

> Please provide feedback by October 18th.

Looks all good to me, except for the nits below:

- you want to update the xml-names reference to 
<http://www.w3.org/TR/2006/REC-xml-names-20060816/>

- you may want to change the xml2rfc list style in Section 5 to "empty"

Best regards, Julian

---

From: Andreas Sewe <[email-masked]>
Date: Mon, 09 Oct 2006 17:18:06 +0200

> for publication as a Proposed Standard to the IESG.

Congratulations!

But while the draft states that "[t]hese [feed] types are complementary" 
(section 1), but is unfortunately silent on how precisely the three 
different types can be used together.

Here are a few questions I still have:

- Is it possible that an Archived Feed Document is marked as complete?
How is this to be interpreted? Does each Archive Document represent a
snapshot of a previous version of the Complete Feed? (This is the
interpretation I lean toward.)

- Is it possible that a Paged Feed's pages (i.e., its feed documents)
are marked as complete? What does this mean? That the Logical Feed in
its entirety, of which each page only contains some entries, is
considered to be complete? (I would answer this question with 'yes', but
note the resulting difference in semantic between complete Archive
Documents and complete pages.)

- Is it possible to serve a single, possibly large Archive Document as
multiple pages? If so, do there have to be "next" links to the
"prev-archive" document, too, or do paging links only cover the current
document. (I would prefer the latter interpretation, as illustrated below.)

    Archive Document 1 ----\                     Archive Document 2
=========================  \                 =========================
Page 1.1 -next-> Page 1.2   \-prev-archive-> Page 1.1 -next-> Page 1.2

Unfortunately I wasn't able to find the answers to these question in the 
draft itself; it is silent on the interactions between the three feed 
types. (In particular, it does not even disallow combining them within a 
single feed!)

So, an explanatory section on the various interactions that might occur 
is probably a good thing to add.

Regards,

Andreas

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 9 Oct 2006 19:32:37 +0200

> - Is it possible that an Archived Feed Document is marked as complete?

By definition, an Archived Feed is a set of Feed Documents, and an
Archive Document is a Feed Document within that set. It cannot be
"complete", unless it is the only one in the set, and therefore
represents the whole Archived Feed as a single Feed Document. It's
"current" link should then point to itself (i.e. the same as the
"self" link).

> are marked as complete?

No.

By definition, a Complete Feed is a single Feed Document.

See:
2.  Complete Feeds

   A complete feed is a feed document that contains all of the entries
   of a logical feed; any entry not actually in the feed document SHOULD
   NOT be considered to be part of that feed.

> multiple pages?

Not sure what you're talking about…
Do you mean a Logical Feed would be split into "stable subsets", each
such subset split into "unstable" Feed Documents?
In this case, as each document is not "stable", it's a Paged Feed, not
an Archived Feed, even if the subset of entries from within 2 Feed
Documents form a "stable subset".
If every Feed Document is "stable", then you have an Archived Feed an
dyou can link Feed Documents to each others using next-archive and
prev-archive.

-- 
Thomas Broyer

---

From: Andreas Sewe <[email-masked]>
Date: Tue, 10 Oct 2006 15:49:45 +0200

> "current" link should then point to itself (i.e. the same as the

Thank you for the clarification; I did not get my terminology straight.

But it would be desirable, IMHO, to be able to link to archived, older 
versions of a complete feed from within the current complete feed document.

Say, a feed document contains this month's Top Ten. Wouldn't it be nice 
if the feed document could link to September's Top Ten, in case anybody 
is interested in all the recent Top Ten lists? And linking to archived 
feed documents is precisely what "prev-archive" and "next-archive" are 
for. So why can't I use them in conjunction with complete feeds?

> No.  By definition, a Complete Feed is a single Feed Document.
> 
> See:
> 2.  Complete Feeds
> 

This is the same reason as to why archived feeds can't be complete. But, 
as I argued above, making an archive of complete feed documents 
available ought to be possible with archived feeds, too.

Now, in contrast to archived feeds, paged feeds serve a different 
purpose: they allow a logical feed to be divided into more easily 
digestible pages. (See the APP draft: "A naive client such as a web 
spider or web browser could be overwhelmed if the response to a GET 
contained every entry in the Collection, and the server would waste 
large amounts of bandwidth and processing time on clients unable to 
handle the response.")

And I can't think of a reason why complete feeds are per se small enough 
to be served without problems as a single document. Granted, the above 
Top Ten list example contains, in all likelihood, only ten entries, but 
what about Top 100s, the Supercomputing Top 500, etc.?

If you accept the usefulness of complete paged or archive feeds for a 
moment, you will see that "completeness" should extend from one page to 
the next (or previous), but not from one archive document to another; 
each archive document is considered complete in its own right.

> Not sure what you're talking about...
 >

This was more or less what I was getting at, and while I recognize the 
issue of stability, being able to page an archive document does make 
sense if you follow the above analysis: 1) archival of complete feeds is 
useful (each archive document will be marked as complete) and 2) even 
complete feeds may need to be paged (each complete archive document 
might be served as several pages).

Putting it all together this leads to a variant of the diagram in my 
previous mail:

Compl. Archive Document 1 -\                  Compl. Archive Document 2
=========================   \                 =========================
Page 1.1 -next-> Page 1.2    \-prev-archive-> Page 1.1 -next-> Page 1.2

Here Archive Document 1 contains, say, last month's Top 100 as a 
complete archive document split into two pages of 50 entries each. It 
then links, via "prev-archive", to August's Top 100 which is again split 
in two.

Does this explanation make sense?

I am aware, now, that this is not what the current draft says, since the 
three types of feed (complete, paged, and archived feed) can't be 
combined in *any* way, even though the draft's introduction claims that 
"[t]hese types are complementary". But at least some of the additional 
expressiveness offered by the combination of complete with either paged 
or archive feeds would be nice to have -- even though it adds some minor 
complexities.

Regards,

Andreas Sewe

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Oct 2006 21:29:27 -0700

I've had a private request to add elements to optionally indicate:
   a) how many pages there are in total, and
   b) what the current page number is
in the case of paged feeds.

What do people think? I note that OpenSearch has something along  
these lines (sort of) already:
   http://www.opensearch.org/Specifications/OpenSearch/1.1#The_. 
22totalResults.22_element

Cheers,

On 2006/10/04, at 11:13 AM, Mark Nottingham wrote:

>
> I've only had positive comments about -07 so far, so I've  
> recommended it for publication as a Proposed Standard to the IESG.
>
> As part of that process, I'm issuing an informal, pseudo-WG Last  
> Call on the document to capture any remaining feedback. In particular,
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Oct 2006 21:32:21 -0700

On 2006/10/10, at 6:49 AM, Andreas Sewe wrote:

> But it would be desirable, IMHO, to be able to link to archived,  
> older versions of a complete feed from within the current complete  
> feed document.
>
> Say, a feed document contains this month's Top Ten. Wouldn't it be  
> nice if the feed document could link to September's Top Ten, in  
> case anybody is interested in all the recent Top Ten lists? And  
> linking to archived feed documents is precisely what "prev-archive"  
> and "next-archive" are for. So why can't I use them in conjunction  
> with complete feeds?

I think you're trying to reconstruct a different dimension; archived  
feeds, when reconstructed, contain only entries that are currently  
considered members of the feed; what you want to do is to have  
snapshots of the feed's members over time, separate from what the  
current members are.

This might work as a "prev-version" link relation...

> This is the same reason as to why archived feeds can't be complete.  
> But, as I argued above, making an archive of complete feed  
> documents available ought to be possible with archived feeds, too.
>
> And I can't think of a reason why complete feeds are per se small  
> enough to be served without problems as a single document. Granted,  
> the above Top Ten list example contains, in all likelihood, only  
> ten entries, but what about Top 100s, the Supercomputing Top 500,  
> etc.?

It isn't a complete feed, then. Completeness is defined as having all  
of the entries in one physical document.

> This was more or less what I was getting at, and while I recognize  
> the issue of stability, being able to page an archive document does  
> make sense if you follow the above analysis: 1) archival of  
> complete feeds is useful (each archive document will be marked as  
> complete) and 2) even complete feeds may need to be paged (each  
> complete archive document might be served as several pages).
>
> Putting it all together this leads to a variant of the diagram in  
> my previous mail:
>
> complete archive document split into two pages of 50 entries each.  
> It then links, via "prev-archive", to August's Top 100 which is  
> again split in two.
>
> I am aware, now, that this is not what the current draft says,  
> since the three types of feed (complete, paged, and archived feed)  
> can't be combined in *any* way, even though the draft's  
> introduction claims that "[t]hese types are complementary". But at  
> least some of the additional expressiveness offered by the  
> combination of complete with either paged or archive feeds would be  
> nice to have -- even though it adds some minor complexities.

My gut feeling is that while there might be some use cases for this  
sort of thing, it's going beyond the 80/20 point, and adding a lot of  
complexity/abstraction. When I said that they were complementary, I  
meant that together, they cover most feeds in common use today, not  
that they can be used together.

I do want to address the combination issue, however. I'm inclined to  
just state that the semantics of feeds that have more than one type  
is undefined by this spec. Does that work for you?

Cheers,

---

From: James M Snell <[email-masked]>
Date: Wed, 11 Oct 2006 23:51:53 -0700

-1. I don't think these would buy us anything we can't already easily
get from OpenSearch.

Mark Nottingham wrote:
> What do people think? I note that OpenSearch has something along these
> lines (sort of) already:
>  
> http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.22totalResults.22_element
> 
> 
> Cheers,
> 
>

---

From: Andreas Sewe <[email-masked]>
Date: Thu, 12 Oct 2006 11:42:21 +0200

Mark Nottingham wrote:
> Andreas Sewe wrote:
>> nice if the feed document could link to September's Top Ten, in case 
>> anybody is interested in all the recent Top Ten lists? And linking to 
>> archived feed documents is precisely what "prev-archive" and 
>> "next-archive" are for. So why can't I use them in conjunction with 
>> complete feeds?
> 
> considered members of the feed; what you want to do is to have snapshots 
> of the feed's members over time, separate from what the current members 
> are.

Right. The point is that for non-complete feeds members are only ever 
added (never removed) as time goes by. Hence you can reconstruct a 
previous revision of an Archived Feed simply by following the 
"prev-archive" links far enough into the past; so there is, for 
non-complete Archived Feeds, no real need for another link relation to 

> This might work as a "prev-version" link relation...

Now there are already "previous" and "prev-archive"; do we really need 
"prev-version" to cover the case of Complete Feeds? At least for 
non-complete Archived Feeds it is not really needed, which gives me the 
gut feeling that "prev-version" might not be needed for Complete Feeds 
either. (Unfortunately, I cannot come up with a satisfactory definition 
for "prev-archive" that would work for both cases, complete and 
non-complete. But that does not mean there is none...)

(For the moment, the "related" link relation with an explanatory @title 
will do.)

>> I am aware, now, that this is not what the current draft says, since 
>> the three types of feed (complete, paged, and archived feed) can't be 
>> combined in *any* way, even though the draft's introduction claims 
>> that "[t]hese types are complementary". But at least some of the 
>> additional expressiveness offered by the combination of complete with 
>> either paged or archive feeds would be nice to have -- even though it 
>> adds some minor complexities.
> 
> My gut feeling is that while there might be some use cases for this sort 
> of thing, it's going beyond the 80/20 point, and adding a lot of 
> meant that together, they cover most feeds in common use today, not that 
> they can be used together.

I see. Maybe it would be a good idea to spell this out explicitly in the 
spec, even if the "Completeness is defined as having all of the entries 
in one physical document" condition implies it. That way you can be sure 
that everyone, me included, gets the semantics right. (FWIW, nothing 
prevents stable logical feeds from being both Archived and Paged Feeds, 
right? Only unstable feeds can just be Paged, not Archived.)

> just state that the semantics of feeds that have more than one type is 
> undefined by this spec. Does that work for you?

It does. It would be worthwhile, however, to state that a future 
revision of your spec might choose to define behavior for these cases. 
(None of the features I have proposed would contradict the current 
semantics of Complete, Paged, and Archived Feeds.)

Regards,

Andreas Sewe

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Oct 2006 16:07:29 -0700

OK. I'm adding this text just after the list of feed types in the  
introduction;

---8<---
The semantics of a feed that combines these types is undefined by  
this specification.
--->8---

WRT what future specs can or can't do, that's pretty much up to them.

Cheers,

On 2006/10/12, at 2:42 AM, Andreas Sewe wrote:

>>> older versions of a complete feed from within the current  
>>> complete feed document.
>>>
>>> Say, a feed document contains this month's Top Ten. Wouldn't it  
>>> be nice if the feed document could link to September's Top Ten,  
>>> in case anybody is interested in all the recent Top Ten lists?  
>>> And linking to archived feed documents is precisely what "prev- 
>>> archive" and "next-archive" are for. So why can't I use them in  
>>> conjunction with complete feeds?
>> I think you're trying to reconstruct a different dimension;  
>> archived feeds, when reconstructed, contain only entries that are  
>> currently considered members of the feed; what you want to do is  
>> to have snapshots of the feed's members over time, separate from  
>> what the current members are.
>
> Right. The point is that for non-complete feeds members are only  
> ever added (never removed) as time goes by. Hence you can  
> reconstruct a previous revision of an Archived Feed simply by  
> following the "prev-archive" links far enough into the past; so  
> there is, for non-complete Archived Feeds, no real need for another  
> link relation to cover this dimension:
>
> Now there are already "previous" and "prev-archive"; do we really  
> need "prev-version" to cover the case of Complete Feeds? At least  
> for non-complete Archived Feeds it is not really needed, which  
> gives me the gut feeling that "prev-version" might not be needed  
> for Complete Feeds either. (Unfortunately, I cannot come up with a  
> satisfactory definition for "prev-archive" that would work for both  
> cases, complete and non-complete. But that does not mean there is  
> none...)
>
> (For the moment, the "related" link relation with an explanatory  
> @title will do.)
>
>>> since the three types of feed (complete, paged, and archived  
>>> feed) can't be combined in *any* way, even though the draft's  
>>> introduction claims that "[t]hese types are complementary". But  
>>> at least some of the additional expressiveness offered by the  
>>> combination of complete with either paged or archive feeds would  
>>> be nice to have -- even though it adds some minor complexities.
>> My gut feeling is that while there might be some use cases for  
>> this sort of thing, it's going beyond the 80/20 point, and adding  
>> a lot of complexity/abstraction. When I said that they were  
>> complementary, I meant that together, they cover most feeds in  
>> common use today, not that they can be used together.
>
> I see. Maybe it would be a good idea to spell this out explicitly  
> in the spec, even if the "Completeness is defined as having all of  
> the entries in one physical document" condition implies it. That  
> way you can be sure that everyone, me included, gets the semantics  
> right. (FWIW, nothing prevents stable logical feeds from being both  
> Archived and Paged Feeds, right? Only unstable feeds can just be  
> Paged, not Archived.)
>
>> I do want to address the combination issue, however. I'm inclined  
>> to just state that the semantics of feeds that have more than one  
>> type is undefined by this spec. Does that work for you?
>
> revision of your spec might choose to define behavior for these  
> cases. (None of the features I have proposed would contradict the  
> current semantics of Complete, Paged, and Archived Feeds.)
>
> Regards,
>
> Andreas Sewe

---

From: James M Snell <[email-masked]>
Date: Mon, 23 Oct 2006 16:42:15 -0700

Mixing things can definitely get a bit wierd.  For instance, if I
structure my archive feeds to show all entries within a given month
rather than by a certain number of entries, each individual feed is both
complete and part of a larger set.  Complete in the sense that each
represents a complete set within a limited window of time.

<feed>
  <id>tag:example.org,2006:archives/200609.xml" />
  <fh:complete />
  <fh:archive />
  <link rel="self" href="200609.xml" />
  <link rel="prev-archive" href="200608.xml" />
  ...
</feed>

- James

Mark Nottingham wrote:
> The semantics of a feed that combines these types is undefined by this
> specification.
> --->8---
> 
> [snip]

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Oct 2006 16:54:33 -0700

Yep. Every feed is, in some sense, complete. And, every feed document  
is potentially part of more than one logical feed.

Many of the use cases take their cues from the surrounding context /  
use case; below you're basically saying:

* If you're subscribing to this URI, you've got the whole thing (and  
BTW, it shouldn't change, because it's an archive).
* If you're putting together an archived feed, and this is one step  
in that, the previous archive is over there.

On 2006/10/23, at 4:42 PM, James M Snell wrote:

>> this

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 24 Oct 2006 10:23:31 +0200

> WRT what future specs can or can't do, that's pretty much up to them.

+1.

//Stefan