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
[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
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
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
* 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
* 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
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.
:-)
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
37 matches
Mail list logo
