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-10.txt [2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13577rfc_flag=0
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I thought the working group was fairly clear about the dubious value and placement of these attributes, and you yourself posted that no one was implementing them, they were strictly informational, and free to be ignored. So you don't think they're important or needed, and then WG doesn't have consensus on them. Even Tim's comments were in the abstract, and not related to feed thread at all. 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. From a technical perspective, the interactions between multiple links with the extension attributes remain unspecified. As a client implementor, I suppose I'll find out what exactly they're for whenever I see the already-completed implementations deployed. In my opinion, the document should do more to inform the community on the role of these attributes. now is the time to step up and make your case. You've merely stated you believe that moving these attributes back to the original location is the right decision. That is not a technical rationale. I would expect to see a more compelling reason, given the clear, technical rationales of those against your decision. On an unrelated note, this document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. -- Robert Sayre
Re: Feed Thread in Last Call
* Robert Sayre [EMAIL PROTECTED] [2006-05-16 04:45]: […] +1 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
Robert Sayre wrote: On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I thought the working group was fairly clear about the dubious value A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. None of the folks I know of that have actually implemented support for the extension has had any problems with them. and placement of these attributes, and you yourself posted that no one was implementing them, they were strictly informational, and free to be ignored. So you don't think they're important or needed, and then WG doesn't have consensus on them. Even Tim's comments were in the abstract, and not related to feed thread at all. I never posted that no one was implementing the attributes. Quite on the contrary, you can pull up quite a few TypePad and Friendster feeds that are using them. You can also look at Sam Ruby's personal blog... or look at my wordpress and roller blog feeds. The attributes are being used. What I did say was that I wasn't aware of anyone using multiple replies links in a single entry and that I personally did not intend on publishing any feeds that used multiple replies links in a single entry. From a technical perspective, the interactions between multiple links with the extension attributes remain unspecified. As a client implementor, I suppose I'll find out what exactly they're for whenever I see the already-completed implementations deployed. In my opinion, the document should do more to inform the community on the role of these attributes. The interaction is unspecified because there is no interaction. As I've said before, the thr:count and thr:when attributes apply only to the atom:link element to which they belong. The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. The roles of the attributes are clearly specified in the spec. There are existing feeds in deployment that demonstrate their use. . On an unrelated note, this document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. My apologies, I thought I had already done so. It will be fixed in the next revision. - James
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. Right, and you're breaking them because...? You haven't coherently explained your reason for moving them back. After all, you agreed with the WG and updated the document, but now you've moved them back for unexplained reasons and pointed at deployments. None of the folks I know of that have actually implemented support for the extension has had any problems with them. I find your answers most unsatisfying and full of circular reasoning that serves mostly to dance around the fact that you and a few others have already deployed. That's been your argument for months now, and the IETF process has a way to deal with that situation: Informational. -- Robert Sayre
Re: Feed Thread in Last Call
Robert Sayre wrote: On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. Right, and you're breaking them because...? You haven't coherently explained your reason for moving them back. After all, you agreed with the WG and updated the document, but now you've moved them back for unexplained reasons and pointed at deployments. Very simple reasons: the attributes are easier to implement, are allowed by RFC4287 and are being used in real deployments. That's more than enough justification for me. I agreed in principle with the arguments presented by David and Aristotle; Accordingly, I drafted up an alternative; Implemented the alternative; Compared the two implementations and the pros/cons of each; Discussed those on the mailing list; and decided in the end that the risk/benefit weighed in favor of the attributes. After testing a number of Atom implementations, I have yet to find one that is broken as a result of using the attributes. - James
