Re: Feed Thread in Last Call
Hello Robert, It's not the IETF which wants to move this on on Standards Track, it's (currently) James as an individual submitter. The IESG just did what it does for all such requests from individuals: Put the document out for IETF Last Call and tell the relevant mailing lists about it. Now it's your (and everybody else's) turn to tell the IESG what you think about this draft. A short, but clearly argued and nicely worded mail, with some easy-to-follow pointers to further material, is all that is needed. This may say okay with Standards Track iff these things get fixed or should be experimental because ... or even too controversial for an individual submission, needs a WG. The time you invest in this email will be a lot better spent than writing yet another mail to James and this list. Lisa (the sponsoring AD) and the rest of the IESG will then look at all the input they get, and will make a decision. Regards,Martin. At 07:03 06/05/17, Robert Sayre wrote: On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 4:33 AM +0200 5/16/06, Robert Sayre wrote: I thought the working group was fairly clear about the dubious value and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. James changed the document in response to those messages. That should be enough. Maybe she could ask James about them. It's not my obligation to spelunk for them, and it's certainly not your place to start making demands like that. So you don't think they're important or needed, and then WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. Well, I'm not going to quibble with you about procedural details. But I have to wonder why they're in the document at all. Looks like the IETF wants to publish a proposed standard explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its individual contributors. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. Well, I don't want to standardize some of what James has deployed. It won't work in Sean's implementation. I'm not sure I can interoperably implement the parts in question. Your two biggest client implementers aren't real happy about this. It might be appropriate if you really stretch, but it's sure not smart. -- Robert Sayre
Re: Feed Thread in Last Call
[snip] - We're talking about adding machine-parsable data that would be invisible to readers of the post content I don't know. The specification says nothing about that. Presumably, the implementers that have already deployed know what they are for. Machine-parseable data that may or may not be presented to users. The spec is silent on how the metadata should be used because there is no reason to dictate how it should be used. Implementations should use it in whatever way they feel is most appropriate. I'm sorry to stir this up again but I've read once more the last FT draft and I still cannot understand the use of the thr:count and thr:when attributes. Well in regards to the context they sit I see their meaning but I cannot see their value. If a feed containg FTE information is meant to be handled by machines only, then those values are not precise enough to be use (but I'd be happy to gearing about them though). If those values are to be presented to users, they are also not precise to have any interest. Besides, say a comment is added to the comments feed. I, as an application developer, will want to update thr:count and thr:when of the entry itself. Meaning that I will have to disregard any If-Modified-Since header sent by an aggregator to check out if my entry has changed when it has actually not changed per se. Anyway, I do not see the value brought by thr:count and thr:when alltogether. Since it is a MAY as well, I hardly see the point of keeping them. Another point is that neither your draft nor RFC 4287 seem to say what a processor, which cannot process a value of the rel attribute, should do. Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case. Finally, if I set a link rel=replies ... / into a feed element, should the ref attribute of the in-reply-to should use the id of the feed or the entry it concerns? If it is the former, aggregators won't be able to correlate threads and entries. - Sylvain
Re: Feed update mechanism
http://blogs.msdn.com/rssteam/archive/2006/04/08/571509.aspx you'll find: Very nice article David, I really like the safe approach taken by Microsoft on this one. Thanks, - Sylvain
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
I'm with Robert here. To clarify what happened with the WebDAV specs he mentioned...: - WebDAV Property Datatypes (RFC4316) hasn't been on the WG's agenda, and currently is implemented only by two vendors. Thus, experimental seems to be absolutely the right category. - WebDAV Redirect References (RFC4437) was on the working group's agenda, but in the end too few implementors seemed to be interested (again: two). Thus experimental wasn't what I would have hoped to achieve, but at least this kind of publication preserves the effort that was invested, and it also documents running code in some implementations. Best regards, Julian
Re: Feed Thread in Last Call
* Eric Scheid [EMAIL PROTECTED] [2006-05-17 14:25]: would this mean this is possible: entry link rel=replies thr:count=5 xml:lang=en href=1 / link rel=replies thr:count=1 xml:lang=fr href=1 / ... /entry You mean `hreflang`, not `xml:lang`, right? I have to say at first blush I don’t see why it should not work, so I find your thought experiment quite amusing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
* Robert Sayre [EMAIL PROTECTED] [2006-05-17 07:25]: I would have said this should go Experimental, +1 We can wait and see what problems crop up in practice with the contested attributes, and whether extensibility according to Sec 6.4. ff (or lack thereof) turns out to be paramount or, to borrow Tim’s turn of phrase, a molehill. If it works out, just reissue it; if not, there’s room to go back and fix it. Sounds reasonable enough to me. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: You mean `hreflang`, not `xml:lang`, right? oops, yes. I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. :-)
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: [snip] If a feed containg FTE information is meant to be handled by machines only, then those values are not precise enough to be use (but I'd be happy to gearing about them though). If those values are to be presented to users, they are also not precise to have any interest. I have no idea what you mean by not precise enough to be used. What makes them imprecise? Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? [snip] Another point is that neither your draft nor RFC 4287 seem to say what a processor, which cannot process a value of the rel attribute, should do. Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case. The spec is silent on this, handle it however you want to handle it in your implementation. IMHO, Good implementations will silently ignore links they don't understand. Finally, if I set a link rel=replies ... / into a feed element, should the ref attribute of the in-reply-to should use the id of the feed or the entry it concerns? If it is the former, aggregators won't be able to correlate threads and entries. The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. - James
Re: Feed Thread in Last Call
I have no idea what you mean by not precise enough to be used. What makes them imprecise? The very fact they don't represent a state that can be trusted. As the spec says they are not the true value but the true value at one given time. Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? Well to take your example a bit further. Say I'm following comments posted to an entry, since there is no way for me to decide if the number provided by the extension is the most up-to-date, I will have to manually go to the source itself and check if someone replied since my last visit. How is that useful to me as an user? Besides you do not answer the question of HTTP caching I mentionned. Basically it would break most planets out there which rely heavily on the '304 Not Modified' status code to check if a feed has been modified. In this case a server such as Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. Clients could of course work around such issue but this is a rather big problem to me. The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. Common sense is one thing, being clearly specified is another one. - Sylvain
Re: Feed Thread in Last Call
The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. By the way, don't get me wrong. I am really looking forward to the FTE replies element but not its attributes which are just useless and counter productive to my liking. - Sylvain
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: I have no idea what you mean by not precise enough to be used. What makes them imprecise? The very fact they don't represent a state that can be trusted. As the spec says they are not the true value but the true value at one given time. The values are no more or less trustworthy than the link's own type, length, and hreflang attributes. I refer you to http://www.w3.org/2001/tag/doc/mime-respect-20060412 Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? Well to take your example a bit further. Say I'm following comments posted to an entry, since there is no way for me to decide if the number provided by the extension is the most up-to-date, I will have to manually go to the source itself and check if someone replied since my last visit. How is that useful to me as an user? If you need an exact count, go to the linked resource. Feed publishers should take steps to ensure that the count is accurate. Again, read the W3C Tag finding referenced above. Besides you do not answer the question of HTTP caching I mentionned. Basically it would break most planets out there which rely heavily on the '304 Not Modified' status code to check if a feed has been modified. In this case a server such as Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. HTTP provides a possible solution to this in the form of a weak entity tag. Also, Feed delta encoding could be leveraged to further mitigate the potential issues. Clients could of course work around such issue but this is a rather big problem to me. I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. - James
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 7:11 AM +0200 5/17/06, Robert Sayre wrote: On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: This document describes an extension to an existing standards-track document: it should either be on standards track or it should not be an RFC. Where is that written down? RFC 2026. That's a long document that's been updated by other process RFCs. Care to point me at the relevant section? I didn't see one. Didn't Julian just get some WebDAV extensions approved as Experimental? Maybe, but that's irrelevant. I don't know much about the IETF, but I do know the process consists mostly of the unwritten rules, rather than the written ones. So, it seems to me that it is very much relevant. In fact, I can quote you on this, from the initial Atom meeting at Sun Microsystems. If you're big on process, the IETF probably isn't for you, or something to that effect. Why the change of heart? The fact that some WGs don't follow the IETF process doesn't mean we should do the same. If our AD (who is also the AD for WebDAV) That's true in the sense that our AD is in the Apps area. However, Ted Hardie is the AD advisor for WebDAV, and those documents were approved before Lisa was an AD, IIRC. But, I suspect you knew all of that. wanted this document to not be on standards track, she would not have put out the IETF last call for the document to be on standards track. OK, phrase it that way. Why does our AD want this document on the standards track? It was clearly designed without much research, no input from client implementers, and contains lots of extra cruft. We also -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
I find it utterly amazing that there is so much contention over two optional attributes that serve a purely informational purpose. If a feed publishers includes them, and a particular feed consumer currently doesn't see a use for them, that feed consumer can ignore them and continue processing the feed with ZERO loss of function. I've started thinking about my schema not as the definition of what this system needs right now but as the definition of what the data should look like if it's present instead. - Tim Ewald, Making everything optional [1] There are some folks for whom the attributes will be useful. I know, for instance, that SixApart has found a use for them in some stuff they are doing with Friendster. I have also used the attributes in a browser-based feed aggregator I've been toying around with. Others may not find a use for the attributes at all. That's ok. If you don't have a use for them right now, **ignore them**. If someone implements support for the attributes and finds that they cause some sort of significant interop issue, that's ok, that's why the IETF process is iterative. Proposed Standards are not set in stone. They can be changed if implementation experience demonstrates that change is necessary. Regarding whether this should be Experimental or a Proposed Standard, I will defer to the judgement of the IESG, however, RFC2026 has the following to say about Proposed Standards: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. ... Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. Seems appropriate to me. Regarding how The Evil Attributes could be used? Given two replies links, entry ... link rel=replies href=1 title=Comments thr:count=10 thr:when=2006-12-12T12:12:12Z / link rel=replies href=2 title=Trackbacks thr:count=5 thr:when=2006-11-11T11:11:121Z / /entry You can display two buttons in a GUI. Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006) Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006) - James [1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2006-05-17 07:25]: I would have said this should go Experimental, +1 We can wait and see what problems crop up in practice with the contested attributes, and whether extensibility according to Sec 6.4. ff (or lack thereof) turns out to be paramount or, to borrow Tim’s turn of phrase, a molehill. If it works out, just reissue it; if not, there’s room to go back and fix it. Sounds reasonable enough to me. Regards,
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
Experience report: Our implementation of comments for AOL blogs includes the count information in a proprietary extension (aj:commentCount), precisely because we need the information for UI purposes. We've found it useful and we'd like to use a more standard extension to help enable interoperability. The one issue we've had with it was with a partner who used a checksum on the retrieved file to determine if something has 'changed' in the feed. We explained how they can use the update timestamps for that purpose and everything was solved. I don't see any issue with these attributes. -John James M Snell wrote: I find it utterly amazing that there is so much contention over two optional attributes that serve a purely informational purpose. If a feed publishers includes them, and a particular feed consumer currently doesn't see a use for them, that feed consumer can ignore them and continue processing the feed with ZERO loss of function. I've started thinking about my schema not as the definition of what this system needs right now but as the definition of what the data should look like if it's present instead. - Tim Ewald, Making everything optional [1] There are some folks for whom the attributes will be useful. I know, for instance, that SixApart has found a use for them in some stuff they are doing with Friendster. I have also used the attributes in a browser-based feed aggregator I've been toying around with. Others may not find a use for the attributes at all. That's ok. If you don't have a use for them right now, **ignore them**. If someone implements support for the attributes and finds that they cause some sort of significant interop issue, that's ok, that's why the IETF process is iterative. Proposed Standards are not set in stone. They can be changed if implementation experience demonstrates that change is necessary. Regarding whether this should be Experimental or a Proposed Standard, I will defer to the judgement of the IESG, however, RFC2026 has the following to say about Proposed Standards: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. ... Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. Seems appropriate to me. Regarding how The Evil Attributes could be used? Given two replies links, entry ... link rel=replies href=1 title=Comments thr:count=10 thr:when=2006-12-12T12:12:12Z / link rel=replies href=2 title=Trackbacks thr:count=5 thr:when=2006-11-11T11:11:121Z / /entry You can display two buttons in a GUI. Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006) Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006) - James [1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2006-05-17 07:25]: I would have said this should go Experimental, +1 We can wait and see what problems crop up in practice with the contested attributes, and whether extensibility according to Sec 6.4. ff (or lack thereof) turns out to be paramount or, to borrow Tim’s turn of phrase, a molehill. If it works out, just reissue it; if not, there’s room to go back and fix it. Sounds reasonable enough to me. Regards,
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: Sections 4.1 describes what is appropriate for standards track; section 4.2 describes what is appropriate for Informational and Experimental RFCs. That's true, but the you asserted the following: This document describes an extension to an existing standards-track document: it should either be on standards track or it should not be an RFC. Where is that written down? Don't see it in RFC2026. In fact, I don't see any of the process we're encountering documented there. I'm disappointed you didn't answer the more interesting and relevant questions in my previous message. -- Robert Sayre
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: entry link rel=replies thr:count=5 xml:lang=en href=1 / link rel=replies thr:count=1 xml:lang=fr href=1 / ... /entry You mean `hreflang`, not `xml:lang`, right? I also meant there to be different hrefs too :-( entry link rel=replies thr:count=5 hreflang=en href=1 / link rel=replies thr:count=1 hreflang=fr href=2 / ... /entry e.
Re: Feed Thread in Last Call
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. so? we have atom:updated to help aggregators detect if there has been a significant change ... everything else is just meta data. e.
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, John Panzer [EMAIL PROTECTED] wrote: I don't see any issue with these attributes. Do you see Windows Feed Platform apps using these attributes? Probably not, huh? Do you consider that lack of interoperation a feature? James M Snell wrote: I find it utterly amazing that there is so much contention over two optional attributes that serve a purely informational purpose. Are we supposed to take this seriously? Since you can't coherently defend a single design decision in the draft, it's safe to conclude this document is not ready to be an RFC. If a feed publishers includes them, and a particular feed consumer currently doesn't see a use for them, that feed consumer can ignore them and continue processing the feed with ZERO loss of function. Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. this should be amusing too: entry link rel=replies thr:count=5 href=1 title=trackbacks! / link rel=replies thr:count=1 href=2 title=comments! / ... /entry e.
Re: Feed Thread in Last Call
Yes. This is possible. What I'm not sure about is whether amusing is good or bad. What point are you trying to make exactly? - James Eric Scheid wrote: On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. this should be amusing too: entry link rel=replies thr:count=5 href=1 title=trackbacks! / link rel=replies thr:count=1 href=2 title=comments! / ... /entry e.
Re: Feed Thread in Last Call
Can't you just ignore them then? The feed update / last-modified issue is not isolated to the use of thr:when and thr:count. As I mentioned in another note, you end up with the exact same problem when folks use the slash:comments element but no one seems to mind that. This problem is not unique to FTE, nor does FTE make the problem any worse. What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. Well to me there is no need to include, or specify, information that cannot be found otherwise already. Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added = 304 Not Modified B. A comment added = I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. - Sylvain
Re: Feed Thread in Last Call
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. so? we have atom:updated to help aggregators detect if there has been a significant change ... everything else is just meta data. e. I'm not sure you have understood me. I'm not talking about the application level but from the HTTP level. If we update the feed each time we update the thr attributes then we screw the HTTP cache big time and waste bandwith. If we don't update them to avoid that issue then those attributes are just useless. Personally I have no interest in doing either way. - Sylvain
Re: Feed Thread in Last Call
HTTP provides a possible solution to this in the form of a weak entity tag. Also, Feed delta encoding could be leveraged to further mitigate the potential issues. ETag are not reliable without If-Modified-Since header and they are not as wide spreaded. I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. This is rather sad. So because others are broken we should not do better. - Sylvain
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: [snip] I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. This is rather sad. So because others are broken we should not do better. No. I'm only just trying to solve one problem at a time. - James
Re: Feed Thread in Last Call
* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-05-17 20:10]: However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: Consider the situation where a weblog only has a single global comments feed – which I strongly favour because having one of them for each entry just does not scale. Then it’s easily possible for some comments to have fallen of the bottom of the comments feed by the time you fetch it to check. In that case, the information in the attributes will be more accurate than the process you describe. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: [snip] What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. Well to me there is no need to include, or specify, information that cannot be found otherwise already. Do you feel the same way about the link element's existing type, title, hreflang, and length attributes? Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added = 304 Not Modified B. A comment added = I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. This boils down to an implementation choice. The thr attributes provide a way for UI's to display something before fetching the feed, which is often useful for an individual to decide whether or not it is even worthwhile to fetch to the comments feed in the first place. Also, consider that comment feeds may span multiple pages (using the paging link rels). With your algorithm (which, yes, is the only authoritative way of determining *exactly* how many comments have been received), you would have to retrieve every page and count up the comments. Considering also that feeds do not necessarily have to be ordered chronologically (tho most are) and that the feed may contain comments to multiple entries, getting a precise count of the total number of comments can be a time and resource consuming process that involves examining every individual entry in the feed for the presence of a matching in-reply-to link. Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. - James
RE: Feed Thread in Last Call
Speaking up: http://www.majordojo.com/atom/standardizing_the_atom_thread_extension.ph p No surprise I guess, but I am a huge +1. Lock this spec down and ship it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Monday, May 15, 2006 3:15 PM To: atom-syntax Subject: Feed Thread in Last Call Hey all, I'm happy to announce that the Feed Thread extension (draft -10) [1] has entered Last Call. [2] The thr:count and thr:when extension attributes are back in Draft -10 following the recent on-list discussion and post by Tim Bray affirming that the atom:link element is indeed extensible. I fully recognize that not everyone on list agrees with this approach, but after trying to propertly implement alternatives, re-reading RFC4287 and surveying folks who I know have already done the work necessary to implement Feed Thread, I believe the decision to keep thr:when and thr:count as attributes is the right decision. At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I have also added Feed Thread support to my Wordpress and Roller blog templates. IBM has plans to ship at least one product with Feed Thread support in the not too distant future (our Atom Publishing Protocol interop/test endpoint currently contains support for Feed Thread). If you do or do not want to see Feed Thread move forward as a Proposed Standard, now is the time to step up and make your case. :-) - James [1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-1 0.txt [2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddT ag=13577rfc_flag=0
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: That's certainly one way of doing things, but not the only way. I'm fairly sure there are existing clients that rely on the thread count (using slash:comments) to determine whether a replies feed has changed. This makes sense when there is a separate feed for each reply - instead of connecting to dozens of feeds looking for updates (and hoping they support 304), you just download the main feed looking for a change in the thread count. If you don't like these attributes, that's fine - nobody is forcing you to use them. But don't assume that everyone wants to do things the same way as you. Don't try and prevent people from doing something different to you just because you personally don't like their choice. Regards James
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: Can't you just ignore them then? The feed update / last-modified issue is not isolated to the use of thr:when and thr:count. As I mentioned in another note, you end up with the exact same problem when folks use the slash:comments element but no one seems to mind that. This problem is not unique to FTE, nor does FTE make the problem any worse. What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. Well to me there is no need to include, or specify, information that cannot be found otherwise already. The use case we've identified here is to be able to quickly display the comment count attribute on a web page where you have 10 entries. We really don't want to have to make 10 extra remote calls to retrieve 10 integers when they are so easily included in the top level entry feed; in fact, should a standard require this, we'd have to shrug and embed the data inside proprietary extensions for performance reasons. Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added = 304 Not Modified B. A comment added = I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. - Sylvain -- John Panzer System Architect, AOL http://abstractioneer.org
Re: Feed Thread in Last Call
If you don't like these attributes, that's fine - nobody is forcing you to use them. But don't assume that everyone wants to do things the same way as you. Don't try and prevent people from doing something different to you just because you personally don't like their choice. The problem I've raised is not about my taste in the end but about making sure we have taken every aspects into consideration. As you said, maybe there are other ways of doing than the basic algorithm I suggested but they do not play on the same level. Anyway, sorry if I came harsh on this question. I didn't mean it but saying that I don't have to use it if I don't like it is not really relevant. We re not discussing what each of us would do but what we want the community to be able to do. James Would you consider adding informative documentation on this matter in the spec or is that out of its boundaries? - Sylvain
Re: Feed Thread in Last Call
This boils down to an implementation choice. The thr attributes provide a way for UI's to display something before fetching the feed, which is often useful for an individual to decide whether or not it is even worthwhile to fetch to the comments feed in the first place. Also, consider that comment feeds may span multiple pages (using the paging link rels). With your algorithm (which, yes, is the only authoritative way of determining *exactly* how many comments have been received), you would have to retrieve every page and count up the comments. Considering also that feeds do not necessarily have to be ordered chronologically (tho most are) and that the feed may contain comments to multiple entries, getting a precise count of the total number of comments can be a time and resource consuming process that involves examining every individual entry in the feed for the presence of a matching in-reply-to link. Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. Fair enough. It sounds reasonable but I'm still not fully convinced. I'm happy we discussed it anyway. Thanks, - Sylvain
Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
Subject: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) From: The IESG [EMAIL PROTECTED] Date: Tue, 16 May 2006 12:53:22 -0700 The IESG has received a request from an individual submitter to consider the following document: - 'Atom Threading Extensions ' draft-snell-atompub-feed-thread-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. The file can be obtained via http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt In section 3, this draft give an xml element corresponding to In-reply-to: (rfc 2822 section 3.6.4). Therefore, the draft do not give an equivalent to References: 822' header field (rfc 2822 section 3.6.4) (wich could be usefull to build a mail -- atom gateway). The section 7.2. do not mention rfc 2822.
Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
Hello Nicolas, thanks for the comments. Nicolas Krebs wrote: [snip] In section 3, this draft give an xml element corresponding to In-reply-to: (rfc 2822 section 3.6.4). Therefore, the draft do not give an equivalent to References: 822' header field (rfc 2822 section 3.6.4) (wich could be usefull to build a mail -- atom gateway). A feed thread element in the form of thr:in-reply-to ref=... / Would serve as the equivalent to the RFC2822 in-reply-to header. And yes, it would likely be good to mention that the in-reply-to element draws some of its inspiration from the smtp in-reply-to header. - James
RE: Feed Thread in Last Call
Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. This to me is what its all about. I hear a lot of people saying that you can't be sure that the comment count is accurate. That the ONLY way to be sure is to get the whole feed with all the comments. To those people I would say you have trust issues. I am being snide, I admit, but truthfully, why would Six Apart (or any other implementer) not want to keep the two values in sync when it is so clear that we SHOULD. Certainly my implementations do. And if they were ever out of sync (i.e. the count attribute saying 5, and the feed containing 6) then that is a bug and I frick'n need to fix that. Byrne
Re: Informational vs. standards-track for Atom Threading Extensions
On May 17, 2006, at 10:02 AM, Robert Sayre wrote: Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? I read this as implying causality between two events. Those two events happened to be near each other in time but weren't causally related. The changes just before the last revision had no impact on my decision to post an IETF Last Call for moving this proposal onto the standards track. It could not have had an impact because I wasn't so closely tuned into the revisions of this draft that I noticed any particular change -- I just reviewed the version presented to me with the shepherding request. My decision to shepherd this document was because I was asked, read the proposal, and felt it was not obviously too harmful and could be useful. It's customary to ask the advising AD for a WG, to shepherd a document closely related to that WG. My decision to recommend Standards Track was because I saw evidence of multiple independent implementations and even some interoperability testing. I could still recommend Experimental instead of Standards Track if I learned of some possible harm to security/privacy or Internet health, or some deep barrier to interoperability, but I have not yet learned of a high enough risk+severity of such concerns to change my mind there. I would be less likely to recommend Informational status for a document like this which has been implemented and has normative statements intended for implementors (e.g. it's not a requirements document or a design overview). Confusingly, Informational is also used sometimes for documents which do not undergo significant community review (e.g. RFC-Editor submissions) but the 4-week IETF last call, previous postings to this list, and comments of implementors, combine to make this document one that is getting significant community review. I hope that makes the situation clearer! Lisa
Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long)
For related work, you could look at the email spam filtering stuff
from SIEVE: http://www.ietf.org/internet-drafts/draft-ietf-sieve-
spamtestbis-02.txt
The similar problem is that many spam libraries already produce some
kind of linear or similar scale of severity/likelihood rating for
emails, much like existing services already provide their own scale
of post rankings. The approach SIEVE took, very roughly, was simply
to tell implementors to find some way to map their implementation's
ranking scheme to a canonical range of numerical values. A SIEVE
implementation might have one algorithm for converting SpamAssassin
rankings to the canonical scale, and a different algorithm for some
different library.
Since spam rankings are intended more for automated filters than for
user display (though clearly the user is sometimes involved in
evaluating the rankings, as when the user creates/edits a mail filter
rule like file all email with a spam rating 5 to spam folder),
the considerations of course could be different from the case of Atom
post rankings.
Lisa
On May 5, 2006, at 7:48 AM, Andreas Sewe wrote:
Having ended up as co-author of the Atom Rank Extensions draft
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-
index-09.txt
I would like to encourage some more discussion on the extension's
features. I would especially like to know whether they are flexible
enough to cope with all the major use cases while being at the same
time
reasonably simple to implement.
The extension should, e.g., be able to cope with most grading
schemes in
use; it needs to be able to describe the set of permissible rank
values
(grades). So we are talking (totally) ordered sets here.
Now the order part is easy; that is what @significance
(=ascending/descending) is for. The hard part is to describe the
underlying set of numbers.
Now the current draft defines two elements, r:value and r:range, for
this purpose. Those two elements can be, however, be collapsed into a
single one, and, with cleverly chosen defaults, defining sets using
this
new r:values element is IMHO as simple, if not simpler, as with the
old
approach. Others might have different opinions, though, which I would
really like to hear about.
At any rate, the proposed change looks basically as follows (Note,
however, that the issue of rounding rank values has intentionally been
left out, since this would only distract from the design issue at
hand.)
The r:scheme Element
Ranking Schemes are defined using the r:scheme element. Each scheme
defines the set of rank values permissible for all r:rank elements
with
the associated scheme.
[...]
The set of rank values defined by an r:scheme element is the union of
the sets of rank values defined by each of its r:values elements.
Note
that those sets may overlap.
The r:values Element
The r:values elements defines a set of rank values, each of which
has to
conform to the XML Schema decimal data type [W3C.REC-
xmlschema-2-20041028].
values = element r:values {
atomCommonAttributes,
attribute minimum { xsd:decimal | unbounded }?,
attribute maximum { xsd:decimal | unbounded }?,
attribute steps { xsd:decimal | continuous }?,
attribute origin { xsd:decimal }?,
undefinedContent
}
The minimum attribute specifies an inclusive lower bound on the
set of
rank values defined by the r:values element. Here, the special
value of
unbounded denotes negative infinity. If not specified, the value of
the minimum attribute is considered to be unbounded.
The maximum attribute specifies an inclusive upper bound on the
set of
rank values defined by the r:values element. Here, the special
value of
unbounded denotes positive infinity. If not specified, the value of
the minimum attribute is considered to be unbounded.
The steps attribute specifies either an increment or has the special
value continuous. If not specified, the value of the steps
attribute is considered to be 0.
The origin element specifies the base from which steps are to be
calculated. If not specified, the value of the origin attribute is
considered to be 0.
If the value of the steps attribute is continuous the set of rank
values defined by the r:values element is
{ x | minimum = x = maximum }.
Otherwise the set of rank values defined by the r:values element is
{ x | minimum = x = maximum,
x = (origin + i * steps) for some integer i }.
The following examples illustrate how different sets of rank values
can
be defined by means of a single r:value element:
!-- The rank value 1 --
r:values origin=1 /
!-- The rank values 1, 2, 3, 4, 5 --
r:values minimum=1 maximum=5 steps=1 /
!-- The rank values 0.0, 0.5, 1.0, 1.5, , 10.0 --
r:values minimum=0.0 maximum=10.0 steps=0.5 /
!-- The rational interval [0, 100] --
r:values minimum=0 maximum=100 steps=continuous /
!-- The integers ..., -2, -1, 0, +1, +2, ... --
r:values steps=1 /
Re: Informational vs. standards-track for Atom Threading Extensions
On 5/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote: On May 17, 2006, at 10:02 AM, Robert Sayre wrote: Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? My question has yet to be answered. I could still recommend Experimental instead of Standards Track if I learned of some possible harm to security/privacy or Internet health, or some deep barrier to interoperability, but I have not yet learned of a high enough risk+severity of such concerns to change my mind there. I think this is an excellent standard. If another individual, such as myself, were to submit an individually authored document, it would have to meet the same standard, right? I hope that makes the situation clearer! Sure does! -- Robert Sayre
