Arve Bersvendsen wrote:
First, I am not too fond of making an autodiscovery protocol "Atom-only"
It's only Atom-only in that it doesn't attempt to dictate things outside the WG's charter: as it's written now, it's just a well-specified exact equivalent of the existing RSS autodiscovery spec-blog-post. Anyone who has existing code for RSS autodiscovery can simply check for one of two values of @type, rather than just one, and be done with it (well, actually, anyone with existing code for RSS autodiscovery has already long since done so).
1) Change the attribute value for the rel from "alternate" to "feed",
Don't forget, since you would be doing that primarily for people who think too much, that you'll also need to include a profile [1] URI and make a guess at what dereferencing that URI ought to return, and probably take a stab at explaining how to deal with multiple profiles, since the HTML spec punted on that.
Popularizing "feed" would have one benefit outside Atom's scope, though: there's currently no useful way for an RSS 1.0 feed to do autodiscovery with type="application/rdf+xml" since it could be any alternate RDF, not just RSS: if Atom breaks the ice with "feed" then RSS 1.0 wins.
2) I am not too fond of requiring a type attribute, since feeds may be served in multiple formats from a single URL.
If you've changed to rel="feed" you've lost all backward compatibility, so you might as well just say type="application/atom+xml" and still do content negotiation for anything that actually prefers RSS: nothing that only knows RSS will recognize you (and what thing that knows Atom would prefer RSS?).
But if you do rel="feed" with no type, then since the namespacing aspect of @profile wasn't ever actually made workable, you are completely claiming the use of that @rel for Atom/RSS: no other past or future things could use it without being willing to take the pounding of a million aggregators.
Phil Ringnalda
[1] http://www.w3.org/TR/REC-html40/struct/global.html#profiles
