On the front page of http://www.mozilla.org/, the RSS news feed is advertised with a discovery tag of the following: <link rel="alternate" type="application/xml" title="RSS" href="http://www.mozilla.org/news.rdf"> But according to this page, the correct "type" should be "application/rss+xml" since "application/xml" is too generic: http://diveintomark.org/archives/2002/06/02/important_change_to_the_link_tag

Well, the really correct media type is application/rdf+xml, because first, it's RDF, and second, because application/rdf+xml is registered by IANA (contrary to application/rss+xml)

It should be 'application/rdf+xml' indeed.

The RSS links on the home page are 'application/rdf+xml' now - marking as FIXED

Whether or not this was the Right Thing, was it a good practical idea? Ten million Firefox users now only autodiscover the mozillaZine feed, and untold millions of users of other readers will probably also not be able to autodiscover the official feeds (surely a few readers have updated versions that discover application/rdf+xml, but just as surely most do not). And while it's the Right Thing in general "the type attribute should be the mime-type the server sends" terms, there is no autodiscovery spec for RSS 1.0 calling for the use of that type attribute, while the general RSS autodiscovery spec, using the unregisterable application/rss+xml, is supported by every reader, and isn't specific to any particular version of RSS (nor does it care what type the server actually sends).

This should be changed back, breaking RSS autodiscovery in Firefox was a bad move. It may be the "right thing" with regard to the type from a server point of view, but it breaks RSS readers that use the RSS autodiscovery type of application/rss+xml, including Firefox.

Has a separate bug already been opened for the fact that Firefox's autodiscovery does not recognize "application/rdf+xml"?

Only in so far as the morphed parts of bug 257247 cover it. However, in the absence of a spec for autodiscovery with application/rdf+xml, can you tell me how to tell RSS 1.0 that's rel="alternate" and type="application/rdf+xml" from any other random bits of RDF that might be an alternate version of the page? Having spent too much time in the RDF camp, I know lots of people who have alternate RDF versions that are not RSS and would choke any RSS reader, much less ours.

fix checked in

(In reply to comment #8) > can you tell me > how to tell RSS 1.0 that's rel="alternate" and type="application/rdf+xml" from > any other random bits of RDF that might be an alternate version of the page? Using the title attribute, like for every RDF sub-langage (like FOAF for example) ( http://www.iwi-iuk.org/cashmere/htdocs/html/newsletter/data/rss.en.shtml ) By the way, a RSS 1.0 parser is firstly a RDF parser, so it can read all application/rdf+xml linked, and find if it is a RSS 1.0 document, or even a general RDF document with bits of RSS...

So, unlike the specs for application/rss+xml and application/atom+xml, both of which explicitly say that the title attribute is human-readable and not significant for autodiscovery, the hypothetical application/rdf+xml spec will make it significant? Will it only be required to include the letters r,s,s anywhere in the title, as in one of the two implementations of FOAF autodiscovery for which the source is available, or will it be required to be exactly and only "RSS" as in the other? What shall the titles for m.o's three feeds then be, "RSS", "RSS", "mozillaZine News"? Saying that "a RSS 1.0 parser is firstly a RDF parser" is very nearly true: I know of two shipping, Live Bookmarks and NewsMonster, and one that may never be done. Other than that, every shipping RSS reader that I know is firstly and only an XML parser, and you forget that RSS 1.0 is only RDF with a sharply constrained XML serialization at your peril. Most RSS consumers will choke on arbitrary RDF, and some will subscribe to it anyway and continue to pull it down every hour until eternity despite their inability to understand it. Simply replacing the mime-type as was done here would effectively prohibit any other use of rel="alternate" type="application/rdf+xml", since RSS readers are so voracious about sucking down bandwidth. But, this isn't the place to design a spec for RSS 1.0 autodiscovery: that ought to happen on its moribund mailing list. The only things that matter here are "is there a spec?" and "do enough RSS consumers implement that spec to allow us to switch?".

(In reply to comment #11) > So, unlike the specs for application/rss+xml and application/atom+xml, both of > which explicitly say that the title attribute is human-readable and not > significant for autodiscovery, the hypothetical application/rdf+xml spec will > make it significant? As I said, that's allready what is done elsewhere The title that should be provided to the user (if you want one) is the feed's one, and not the title of the link. > Simply > replacing the mime-type as was done here would effectively prohibit any other > use of rel="alternate" type="application/rdf+xml", since RSS readers are so > voracious about sucking down bandwidth. Removing the application/rdf+xml type will block autodiscovery by scatterbots. And there are more differences between RSS 1.0 and RSS 2.0 than between RSS 2.0 and Atom : why should the first two use the same media type, when applications could understand one and not the other ? If you claim that all aggregators understand both, then they understand atom too : so why does it use a different media type ? With the solution used (with RDF media type), the 3 types are recognizable immediatly. I know many blog engines that use it, so RSS consumers should implement it...

> The title that should be provided to the user (if you want one) is the feed's > one, and not the title of the link. That's something different entirely. The title="" attribute of the <link> element is meant to be human-readable for all <link> elements so they can be used in the <link> UI. RSS feeds should certainly not be an exception to this. You can present a title="" as the label for the link if there is one, but you can't get the feed's title unless you download it.

Certainly RSS 1.0 and RSS 2.0 *should* use different mime-types: that they both have historically used application/rss+xml is one of the biggest reasons it is completely unregisterable. But having RSS 1.0 switch to an unspecified autodiscovery scheme using a mime-type that is not specific to RSS 1.0, and using the content of the title attribute as machine-significant (the presence of a title is significant with stylesheets, but I know of no link-using scheme where the content is significant) is something that needs to be pulled by a spec and support by clients, not pushed by pages changing to ad-hoc tags that silently fail until enough client authors notice. Wake RSS-DEV from its slumber, get agreement on an actual spec, and I'll patch Firefox and talk to all the aggregator authors I know about supporting it (though at least one almost certainly won't, ever), and *then* switch mozilla.org's <link>s. I'll be happy to debate the merits of machine-significant @title on RSS-DEV, but until that's done I'm done spamming this bug, because there's nothing to be done here until after there's a spec, and this isn't the place to write it.

(In reply to comment #13) Of course it's different. But what do you think a user will prefere : to see the link title or the feed title ? And downloading isn't a problem, browser allready do this with other linked documents... Phil Ringnalda, you seem to be reading RSS-dev mailing list. Maybe you could just show them this bug ?