Re: The atom:uri element
On Mon, 2005-06-27 at 12:46 -0700, James Cerra wrote: Please can we have an informative version of the spec, with the semantics explained. Current version, for thicko's|users, like me, is not good. How hard is one little change? I'm not looking for a change. That has been submitted. I'm looking for an informative, not normative, version of the spec, which takes time to explain things instead of being exact, but backed by the experience of this list? Yes, I know the spec is for implementors, but there are authors out here too, who need that information. That I believe is the interop issue. -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
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 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/
Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
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
Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
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
Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
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: 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. This is poorly worded; your 'batches of 15' scenario is what I had in mind. I'll work on better language for -01. 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). 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! -- Mark Nottingham http://www.mnot.net/
Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
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. 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 -- Mark Nottingham http://www.mnot.net/
Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
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: 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). 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.