Re: Feed Thread in Last Call
* James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]: The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. Supply per-link information as namespaced attributes on link elements, if you must. I don’t like the idea, but it seems there is unfortunately no way to associate link-specific RFC 4287 Simple or Structured Extension Elements with a link. (But why `thr:when` rather than `thr:updated`?) However, don’t neglect to provide a way to supply a global reply count. That would break the argument that the FTE covers nearly every threading use cases without having to resort to a gaggle of other extensions and hence weaken FTE’s position, IMO. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: Very simple reasons: the attributes are easier to implement, Speaking as an actual, rather than alleged, client implementer, I find this assertion ridiculous and dishonest. are allowed by RFC4287 and are being used in real deployments. So, the argument is that it's already deployed, then? It looks like you agree with me. -- Robert Sayre
Re: Feed Thread in Last Call
A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]: The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. Supply per-link information as namespaced attributes on link elements, if you must. I don’t like the idea, but it seems there is unfortunately no way to associate link-specific RFC 4287 Simple or Structured Extension Elements with a link. (But why `thr:when` rather than `thr:updated`?) RFC4287 does not forbid simple or structured extension elements on link. However, don’t neglect to provide a way to supply a global reply count. That would break the argument that the FTE covers nearly every threading use cases without having to resort to a gaggle of other extensions and hence weaken FTE’s position, IMO. I will consider adding a thr:count element to the spec to cover the global count case. - James
Re: Feed update mechanism
Tuesday, May 16, 2006, 11:18:04 AM, Sylvain Hellegouarch wrote: Hi everyone, These days It seems that when UAs request a server to check if a feed has changed the server responds with either an HTTP 304 Not Modified status code or by returning the updated feed. It looks to me as a problem if only one or a couple of entries have been updated within the feed as it wastes so much bandwith specially when the said feed contains all entries being produced on the server. Check out A-IM: feed [1]. It is already implemented by lots of aggregators, and it is trivial for client implementors to support. [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html -- Dave
Feed update mechanism
Hi everyone, These days It seems that when UAs request a server to check if a feed has changed the server responds with either an HTTP 304 Not Modified status code or by returning the updated feed. It looks to me as a problem if only one or a couple of entries have been updated within the feed as it wastes so much bandwith specially when the said feed contains all entries being produced on the server. Below are ideas I had about that issue. Nothing formal. PROPOSAL 1 == 1. An UA requests the feed for the first time, the server returns the full current feed. The UA stores it in its cache 2. The UA requests the feed again and provide the If-Modified-Since header a. No changes done, the server returns a 304 Not Modified b. The server checks which entries have been updated or published since that date and returns a feed containing only those. The UA updates its copy of the feed with the incoming data. The big issue with this algorithm is that it adds semantic to the HTTP caching system by expecting the UA to update its copy of the feed instead of simply replacing it. Although specific aggregators could do it, it is more than likely that some clients would just replace their copy of the feed and confuse the end user. PROPOSAL 2 == 1. An UA requests the feed for the first time, the server returns the full current feed. The UA stores it in its cache 2. The UA requests the feed again but provides a time range like this: http://host/feed?after=2003-12-13T18:30:02Zbefore=2003-12-13T19:30:02Z a. No changes done, the server returns a 304 Not Modified b. If entries have been published or updated in the time range, then return a feed with those only. Of course, one might only pass either 'after' or 'before'. The problem with this proposal is to add parameters to the URI which might not be handled by the server. There are a few ways to handle that: * The UA could also use the OPTIONS method from HTTP to check if the server supports the said URI. * The client sends the requests and the server could return 400 Bad Request if it cannot handle it. In order to deal with those proposals we could add a simple extension to a feed such as atom:feed update-method=full|incremental|chunk When receiving the feed for the first time the client would know if it can either request for: * full = default to fetch the complete feed each time when it has been modified. The default behavior as it exists today. * incremental = the server says it can serve entries published or updated after a given date (equivalent to using only the 'after' parameter in PROPOSAL 2 or PROPOSAL 1) * chunk = the server says it can serve feed of entries published or updated between two dates (as explained in PROPOSAL 2) These are just some thoughts and there might already be ways of dealing with this. If not I'd be happy to hearing your feedback. - Sylvain http://www.defuze.org
Re: Feed update mechanism
Hi Dave, Check out A-IM: feed [1]. It is already implemented by lots of aggregators, and it is trivial for client implementors to support. [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html Very nice article indeed and it shows I'm not the only wondering about this. The A-IM idea is pretty neat and efficient apparently. I'll give it a look. Thanks, - Sylvain
Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
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. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt
Re: Feed Thread in Last Call
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. 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. In the IETF, individuals can submit documents to become RFCs without those documents being Working Group items. This document (and all of the other format extension documents out there) fall into that category. If the author asks an Area Director to have the document published as a standards-track RFC, the AD will most likely ask for input on any relevant mailing list, including any existing WG mailing lists. 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. --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread in Last Call
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
Robert Sayre wrote: [snip] 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. ...explicitly designed to break a very popular implementation!? Give me a break. I've been purposefully judicious lately not to respond to crap like this but given the Last Call status on the spec, I think several very clear points need to be made: 1. My decision to use the attributes has absolutely nothing to do with Microsoft's implementation. In fact, the attributes were introduced to the spec *before* I knew any details about the Microsoft implementation. Any claims to the contrary are false. Any claims that I *explicitly designed* the extension to break a particular vendor implementation borders on the downright absurd. 2. Microsoft's implementation is no more broken by the use of the attributes than any other feed reader implementation that has not been specifically modified to support the extensions. I use Liferea, it can't do anything with the thr:count or thr:when attributes either. I guess that means I exlicitly designed the spec to break Liferea as well? Microsoft's implementation doesn't support multiple enclosures, so I guess RFC4287 was explicitly designed to break their implementation? Please, enough. I asked Byrne Reese if he could load up Sam Ruby's personal blog feed in IE7 and capture a screenshot. Sam's feed uses the thr:count and thr:when attributes. IE7 worked as expected, properly ignoring the extensions it does not understand. http://www.snellspace.com/public/ie7screen.png What's broken? - James
Re: Feed Thread in Last Call
On 5/17/06, James M Snell [EMAIL PROTECTED] wrote: What's broken? Do you think the AD and this WG are dumb? Why are you setting up such an obvious strawman? Congratulations, your extension didn't break Atom. The point is that your extension is broken. You're including attributes in that document that you know won't be visible to a large number of implementations. You have no technical reason that makes that location compelling, and several WG members have questioned whether this document adequately covers the area in question. In fact, you appear unable to explain the rationale behind any technical decision without resorting to circular reasoning, logical fallacies, and claims that are outright false. -- Robert Sayre
Re: Feed Thread in Last Call
* Robert Sayre [EMAIL PROTECTED] [2006-05-17 01:50]: You have no technical reason that makes that location compelling, and several WG members have questioned whether this document adequately covers the area in question. I have to disagree that there is no technical reason. There is no way to sanely associate additional information with a link element. I suggested an approach based on cross-referencing with the `href` value, but interactions with xml:base invalidate that approach. Other than `href`, there is no other hook on `atom:link` which could be used for cross-referencing without resorting to microparsing hacks. The root of the problem is a miniscule omission in RFC 4287: Sec 6.4. does not list `atom:link` as a location for Metadata elements. It should have. The effect is that links in Atom can only be extended at the XML level, not at the model level. There is no other reasonable choice for the FTE than to supply this information as namespaced attributes on the link element. This is now clear. I hate the idea as much as you do, but RFC 4287 is what it is. In fact, you appear unable to explain the rationale behind any technical decision without resorting to circular reasoning, logical fallacies, and claims that are outright false. That doesn’t mean there is *no* reason for any of these technical decisions. But I agree that James has advocated the position he chose on this particular issue extremely poorly, just as you’d have done your own argument a favour by omitting your interpretation of the matter as vendor politics. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
The IESG wrote:
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. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt
I'm -0 this becoming a Proposed Standard. I think this is really cool,
has room for interop problems, probably has security issues, and thus is
arguably premature/innovative and could be considered informational.
One reason I think it's cool is not for commenting support but for cheap
full duplex/reliable messaging - traditionally a SOAP use case.
FTR, I have no implementation experience with Feed Thread, haven't
studiously followed the discussion on atom-syntax and that basis feel my
opinion doesn't count for that much.
== Multiple references
thr:in-reply-to
ref=tag:entries.com,2005:1
type=application/xhtml+xml
href=http://www.example.org/entries/1/
In particular the RNC:
in-reply-to =
element thr:in-reply-to {
atomCommonAttributes,
( ref, source?
| href, type?
| ref, source?, href, type? )
}
varies in co-occurrence constraints. No one attribute seems to be
required in all cases, which is a problem imo (if I'm wrong I'll argue I
still have a point that it's unclear what an implementor should look
for). I think this will be an interop headache and that either ref or
href should always be required. Naturally ref to atom:id is to spec the
right choice, but in practice it seems the first thing anyone will want
to do unless they are the authority for the comment *and* the entry is
pull down what's being replied to via href. Otoh, mandating ref implies
as yet undeployed/unstandardised lookup/query services for atom:id - we
have enough experience now with identity lookup services
(CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service
won't ever be deployed uniformly, or will be deployed in a way that
isn't some kind of SPOF or business model or outright failure. That, or
the feature will end being limited to local cases where ref is preferred
over href (point to point integrations come to mind, hence the mention
of SOAP).
This of course is fallout from the way identity in Atom is specced,
which is also a hedge. Feed Thread imvho should consider getting off the
fence on id v link and providing guidance for follow on extensions.
== @rel optionality
[[[
allow Atom clients that are not familiar with the in-reply-to
extension to know that a relationship exists between the entry and
the resource being responded to, publishers are advised to consider
including a related link referencing a representation of the
resource identified by the in-reply-to element.
]]]
I think to do anything useful with this relation you would have had
enough code written to switch on thr:in-reply-to to begin with. It could
be struck.
== Interop
There are multiple publishing options in terms of how to associate
comments with entries/comments. That this hasn't bitten anyone yet seems
to me to be a combination/result of lack of implementations targeting
the feature, Atom's mU policy for extensions, and (possibly) a lack of
experience with comment aggregation across publishing and aggregating
authorities.
Do the WG believe this will work out with multiple authorities using
multiple stacks?
== Security
[[[
As this specification defines an extension to the Atom Syndication
Format, it is subject to the same security considerations as defined
in [RFC4287].
]]]
I have a serious enough quibble with this statement (the ddos attack
note notwithstanding). As an atom foreign markup extension, it's true on
the face of things, but the thr:reply-to semantics introduce
attribution/repudiation issues as well as providing aggregator/planet
spamming options. IOW thr:in-reply-to seems to standardise the same
attack/spam vectors we see in mail for feeds and this needs to be
acknowledged given spam mail is a multi-billion dollar sinkhole (or
industry depending on the pov). That's a dramatic way to state things
sure, but not without some truth. So - where's the digest/sig hook?
James, you know this stuff... :)
cheers
Bill
Re: Feed Thread in Last Call
On 5/17/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to disagree that there is no technical reason. There is no way to sanely associate additional information with a link element. Sure there is, and it's the way James did it. Is the information valuable? Does the spec cover cardinality issues? Is the link element useful here? Was the spec less effective in its previous incarnation? The answer to all of these questions is no. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
Bill,
Thank you very much for the detailed feedback. Comments inline.
Bill de hÓra wrote:
[snip]
I'm -0 this becoming a Proposed Standard. I think this is really cool,
has room for interop problems, probably has security issues, and thus is
arguably premature/innovative and could be considered informational.
I am not opposed to informational status for the extension. I would
prefer Standards Track, of course, but in general, In general, I have a
number of deep concerns over whether or not there is enough of a
consensus in the Atom community about the right ways of extending the
format. It may very well make more sense to hold off on standardizing
any extensions to the format until the community has had more time to
figure out the right approach. Perhaps it would also make sense to
consider a formal WG focusing on Atom extensions.
[snip]
== Multiple references
thr:in-reply-to
ref=tag:entries.com,2005:1
type=application/xhtml+xml
href=http://www.example.org/entries/1/
In particular the RNC:
in-reply-to =
element thr:in-reply-to {
atomCommonAttributes,
( ref, source?
| href, type?
| ref, source?, href, type? )
}
varies in co-occurrence constraints. No one attribute seems to be
required in all cases, which is a problem imo (if I'm wrong I'll argue I
still have a point that it's unclear what an implementor should look
for). I think this will be an interop headache and that either ref or
href should always be required. Naturally ref to atom:id is to spec the
right choice, but in practice it seems the first thing anyone will want
to do unless they are the authority for the comment *and* the entry is
pull down what's being replied to via href. Otoh, mandating ref implies
as yet undeployed/unstandardised lookup/query services for atom:id - we
have enough experience now with identity lookup services
(CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service
won't ever be deployed uniformly, or will be deployed in a way that
isn't some kind of SPOF or business model or outright failure. That, or
the feature will end being limited to local cases where ref is preferred
over href (point to point integrations come to mind, hence the mention
of SOAP).
This of course is fallout from the way identity in Atom is specced,
which is also a hedge. Feed Thread imvho should consider getting off the
fence on id v link and providing guidance for follow on extensions.
This design stems from a design decision to support responses to
resources that do not have an Atom representation (and therefore no
atom:id to reference). Alternatively, the resource being responded to
may only exist as an entry within an Atom feed and therefore only be
referenceable via it's atom:id. Or, the resource being responded to may
only exist as an item within an RSS feed that has no guid NOR a stable
URI that may be used to reference it.
We could require ref at a minimum. Doing so would require that
implementations using the element to reference non-Atom resources would
be required to come up with some way of uniquely identifying those
resources. I think this is acceptable as I believe it safely covers the
majority of the use cases.
I do not believe that mandating ref would require any kind of atom:id
lookup mechanism.
== @rel optionality
[[[
allow Atom clients that are not familiar with the in-reply-to
extension to know that a relationship exists between the entry and
the resource being responded to, publishers are advised to consider
including a related link referencing a representation of the
resource identified by the in-reply-to element.
]]]
I think to do anything useful with this relation you would have had
enough code written to switch on thr:in-reply-to to begin with. It could
be struck.
Agree.
== Interop
There are multiple publishing options in terms of how to associate
comments with entries/comments. That this hasn't bitten anyone yet seems
to me to be a combination/result of lack of implementations targeting
the feature, Atom's mU policy for extensions, and (possibly) a lack of
experience with comment aggregation across publishing and aggregating
authorities.
Do the WG believe this will work out with multiple authorities using
multiple stacks?
What kinds of issues are you anticipating would be a problem?
Specifically, I'm not sure what you mean by There are multiple
publishing options in terms of how to associate comments with
entries/comments.
Can you expand a bit on this?
== Security
[[[
As this specification defines an extension to the Atom Syndication
Format, it is subject to the same security considerations as defined
in [RFC4287].
]]]
I have a serious enough quibble with this statement (the ddos attack
note notwithstanding). As an atom foreign markup extension, it's true on
the face of things, but the
Re: Feed Thread in Last Call
On 5/17/06, Lisa Dusseault [EMAIL PROTECTED] wrote: - We're talking about visibility to implementations of the base spec only, not implementations of the extension, naturally. Any new information can be visible to implementations of that extension. There's a misunderstanding here. Many applications rely on a feed parsing service provided by the OS or a language-level library. Some of those platforms (MS is not the only one) don't provide access to extension attributes on the link element. For example, entry ... foo:bar / link foo:bar=baz ... / /entry here the extension attribute stands a chance of getting lost. The reason this occurs is because it's much easier to design an API that doesn't deal with these things in the general case. This situation could change in the future, as Atom consumer APIs develop. My implementation will parse and preserve the attribute, but I'm not sure what I'm supposed to do with it at an application level, especially if I encounter more than one such link element. As a result, I see no reason to introduce gratuitous compatibility problems when the cardinality of the link element doesn't seem to suit the problem very well. - 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. -- Robert Sayre
Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
At 1:20 AM +0100 5/17/06, Bill de hÓra wrote: I'm -0 this becoming a Proposed Standard. I think this is really cool, has room for interop problems, probably has security issues, and thus is arguably premature/innovative and could be considered informational. 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 niggle on a particular document. 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. If the document has room for interop problems, and/or security issues, they should be stated so that the sponsoring AD, and the IESG as a whole, can decide whether or not the document is ready to be an RFC, regardless of the type of RFC it will become. --Paul Hoffman, Director --Internet Mail Consortium
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: 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? Didn't Julian just get some WebDAV extensions approved as Experimental? You seem to be saying IETF participants don't get to have anything other than a black/white opinion on the readiness of this document. I disagree, and I also think it's kind of inappropriate for you to be managing discussion in this way. After all, it's not a WG document, is it? I would have said this should go Experimental, but it's not clear that the author is willing to change the document in any meaningful way, so there's no experiment to conduct. Informational and Experimental RFCs The role of Informational RFCs is often debated in the IETF. Many people like having them, particularly for specifications that were created outside the IETF but are referenced by IETF documents. They are also useful for specifications that are the precursors for work being done by IETF Working Groups. On the other hand, some people refer to Informational RFCs as standards even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting. When this happens, the debate about Informational RFCs is renewed. Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them, or whether they will work once deployed. That is, a specification might solve a problem, but if it is not clear that many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC. If, later, the specification becomes popular (or proves that it works well), it can be re-issued as a standards-track RFC. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards track material, but for which there are still unanswered questions. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
