Re: The atom:uri element

2005-06-28 Thread Dave Pawson

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

2005-06-28 Thread Mark Nottingham


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

2005-06-28 Thread Garrett Rooney


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

2005-06-28 Thread Antone Roundy


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

2005-06-28 Thread Mark Nottingham


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

2005-06-28 Thread Mark Nottingham


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

2005-06-28 Thread Antone Roundy


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.