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

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jul 2005 13:40:06 -0700

This draft is based on comments received; thanks to everyone. Major  
changes;

* Removed 'this' link
* Changed link syntax
* Changed stateful syntax
* Clarified difference between 'subscription' and 'archive' feeds  
(note that they're just for the purposes of clarity in this spec)
* Added a bit to the state reconstruction process description
* Added examples

I've also modified my personal blog feed to demonstrate how this  
would be published; see
   http://www.mnot.net/blog/index.rdf
Note that this uses a temporary namespace (none is yet in the spec)  
and is implemented completely in vanilla Moveable Type 2.x templates.

Comments and suggestions welcome as always,

> 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-01.txt
>         Pages           : 10
>         Date            : 2005-7-1
>
> 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-01.txt
>
> 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-01.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-01.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.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <ftp://ftp.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
> history-01.txt>

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

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 05 Jul 2005 00:18:46 +0200

> * Added a bit to the state reconstruction process description

Really good work!

> Comments and suggestions welcome as always,

Why not using an xs:boolean for fh:stateful? hence allowing values 0, 1, 
true and false.

With the -01 draft (it might have been the same within the -00 one too), 
one can't reuse the process to link to archives of "Top Twenty Records" 
or "Most Popular Items" (e.g. a monthly "Top Twenty Records" linking to 
the previous-month "Top"), because of the "a subscription document whose 
fh:stateful element contains "false" MUST NOT contain a fh:prev element".
Why not just stating that if fh:stateful is false then the "prev"-linked 
archive feed doesn't not contain a subset of the previous entries but 
rather does contain the previous state of the subscription feed. I.e. 
the meaning of the fh:prev "link" depends on the value of fh:stateful.

Also, shouldn't there be a note to invite producers to provide an 
atom:link@rel="self" referencing the subscription feed?

I also repeat my proposal for an identifier different from an URI for a 
reader/aggregator to know whether it has already retrieved an archive 
document, e.g. using the "updated" date-time of the "fh:prev"-linked 
archive feed.

Example:
   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-09"
     xmlns:history="[TBD]">
     <title>Example Feed</title>
     <link href="http://example.org/"/>
     <updated>2003-12-13T18:30:02Z</updated>
     <author>
       <name>John Doe</name>
     </author>
     <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
     <history:stateful>true</history:stateful>
<!--
added an "updated" attribute with tha atom:updated value
of the http://example.org/2003/11/index.atom document.
-->
     <history:prev updated="2003-11-24T12:00:00Z">
       http://example.org/2003/11/index.atom</history:prev>

     <entry>
       <title>Atom-Powered Robots Run Amok</title>
       <link href="http://example.org/2003/12/13/robots_here"/>
       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text in a new, fresh entry.</summary>
     </entry>

   </feed>

If I retrieved the feed between 2003-11-24T12:00:00Z and 
2003-12-13T18:30:02Z, the fh:prev URI were probably equal to 
http://example.org/2003/10/index.atom (october, not november). However, 
I didn't miss any entry.
Using the fh:prev@updated value, I can know that I didn't miss any entry 
and that I then don't need to dereference 
http://example.org/2003/11/index.atom (november, the "new" fh:prev URI)

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 Jul 2005 21:45:20 -0700

> Really good work!

Thanks!

> Why not using an xs:boolean for fh:stateful? hence allowing values  
> 0, 1, true and false.

I did it this way because I'm not a huge XML Schema fan :)

At this point, stateful is effectively xs:boolean with a constraint  
on the lexical space. I'm not against changing it to '"1" or "true" /  
"0" or "false", except that this makes the spec more verbose (but  
that's a pretty minor concern, properly managed). What do others  
think (in either direction)?

> With the -01 draft (it might have been the same within the -00 one  
> too), one can't reuse the process to link to archives of "Top  
> Twenty Records" or "Most Popular Items" (e.g. a monthly "Top Twenty  
> Records" linking to the previous-month "Top"), because of the "a  
> subscription document whose fh:stateful element contains "false"  
> MUST NOT contain a fh:prev element".
> Why not just stating that if fh:stateful is false then the "prev"- 
> linked archive feed doesn't not contain a subset of the previous  
> entries but rather does contain the previous state of the  
> subscription feed. I.e. the meaning of the fh:prev "link" depends  
> on the value of fh:stateful.

That's interesting, but it somewhat changes the semantics of "prev";  
it goes from "where you can find previous entries in a logical feed"  
to "where you can find an older archive of entries." While these are  
often the same thing, it might not always be the case; i.e., someone  
might want to publish a non-time-based feed.

So, I'm nervous about having two different semantics for one element,  
depending upon its context of use.

> atom:link@rel="self" referencing the subscription feed?

Agreed. Ideally, Atom would have separate concepts of 'syndication'  
and 'archive' feeds, and make this recommendation itself. As it is,  
the semantic of 'self' in an archive feed is a bit fuzzy.

> I also repeat my proposal for an identifier different from an URI  
> for a reader/aggregator to know whether it has already retrieved an  
> archive document, e.g. using the "updated" date-time of the  
> "fh:prev"-linked archive feed.
>
> Example:
> 2003-12-13T18:30:02Z, the fh:prev URI were probably equal to http:// 
> example.org/2003/10/index.atom (october, not november). However, I  
> didn't miss any entry.
> Using the fh:prev@updated value, I can know that I didn't miss any  
> entry and that I then don't need to dereference http://example.org/ 
> 2003/11/index.atom (november, the "new" fh:prev URI)

Hmm, that seems awfully complex (and hard to grasp -- but maybe it's  
just me :) just to avoid a round trip. That 'probably' is also  
worrying me. How would you express this in the 'reconstructing state'  
section?

Cheers,

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 11 Jul 2005 08:53:36 +0100

Mark Nottingham wrote:
>> Why not using an xs:boolean for fh:stateful? hence allowing values 0,
>> 1, true and false.
> 
> 
> At this point, stateful is effectively xs:boolean with a constraint on
> the lexical space. I'm not against changing it to '"1" or "true" / "0"
> or "false", except that this makes the spec more verbose (but that's a
> pretty minor concern, properly managed). What do others think (in either
> direction)?

1. I don't want to have to link to an XSD library in my XML toolchain
just to process true/false in an attribute.

2. I don't want to hack some code together to recognize a single XSD
primitive just because I don't want to link to an XSD library.

cheers
Bill