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 h

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: The similar problem is that many spam libraries already produce some kind of linear or similar scale of severity/likelihood rating for

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

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 su

RE: Feed Thread in Last Call

> 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 entr

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 b

Re: Feed Thread in Last Call

Sylvain Hellegouarch wrote: > James > Would you consider adding informative documentation on this > matter in the spec or is that out of its boundaries? What I intend to do is provide a fairly short section discussing the use of the thr attributes, a few comments regarding the precision and autho

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

My major issue here is not really whether or not those attributes exist but the fact that there is no real review of their implications. We mainly hear of how useful they can be for some existing implementations but it'd be a shame to realize in a couple of years that they were in fact bringing mo

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: > > - 'Ato

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, conside

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 probl

Re: Feed Thread in Last Call

On May 17, 2006, at 9:36 AM, Sylvain Hellegouarch wrote: 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 s

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 se

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 th

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:

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

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

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. > > Th

Re: Feed Thread in Last Call

* Eric Scheid <[EMAIL PROTECTED]> [2006-05-17 19:10]: > I also meant there to be different hrefs too :-( Oh! I thought that was the point – the idea being that you can express (roughly – not precisely) that there are X entries in SomeLanguage at $some-uri and Y entries in OtherLanguage at the sam

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 cur

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 hel

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 >

Re: Feed Thread in Last Call

Sylvain Hellegouarch wrote: >> 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 u

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, >>

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: ... 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 ther

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

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? I also meant there to be different hrefs too :-( ... 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, 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

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

Excellent, thank you. John Panzer wrote: > 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

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 intero

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 th

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

At 6:08 PM +0200 5/17/06, Robert Sayre wrote: On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote: >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. Sections 4.1 describes wha

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 >

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 valu

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

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

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 h

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

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. Didn't

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: 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 bo

Re: Feed Thread in Last Call

* Eric Scheid <[EMAIL PROTECTED]> [2006-05-17 14:25]: > would this mean this is possible: > > > > > ... > 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, -- A

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 Ref

Re: Feed Thread in Last Call

On 17/5/06 11:38 AM, "James M Snell" <[EMAIL PROTECTED]> wrote: > This will be fixed in the next revision of the draft. The short answer > is: every "replies" link MUST be processed independently of any others. > That is, the feed consumer MUST NOT assume that multiple replies links > are all ju

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: 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 d

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

Paul Hoffman wrote: These are not reasons to make something an Informational RFC. In the minds of developers, there is no difference between Informational and standards-track RFCs. The IETF's differentiation between types of RFCs has always been confusing, but that is not a reason for us to n