Duncan Mackenzie: FeedValidator.org tells me that the main
MSDN feed
(http://msdn.microsoft.com/rss.xml) is
invalid, because we have enclosures with a MIME type of
type="text/html; charset=utf-8", but I believe that is a valid
value...
It appears that I will never be done learning. I had
assumed that
charset was a
Content-Type header parameter, instead such parameters are
considered part of the
media type.
It makes me wonder what an aggregator is supposed to do with such a thing. Is it just supposed to be a link?
Robert, that was exactly what I wondered. I guess you do the same thing that you do with all other enclosures, download the content (curl -o) to some location on the local machine and give the user a way to view it. Here’s the question though - the first such enclosure I found was 302 - fine, I can follow the redirect. But the page that comes up is loaded with relative links, so I’m faced with either downloading a page with a ton of broken links, of fixing up relative links, which means now I’m munging content of an enclosure - presumably based upon the media type, though no doubt someone will think up an interesting application for remixing MP3 enclosures.
The MIME RFCs don’t give an accurate definition for the term “media type”. In some places the term is used to mean a top-level type, such as “text”; in some places it includes the sub-type too, such as “text/html”; in other places it includes parameters, such as “text/html; charset=utf-8”.
Atom couldhavebeen clearer with the terminology, but as it is, I’d assume that parameters are allowed.
A quick decision about whether autodiscovery meant mime-type or type plus subtype only would be a big help to me: it took me 11 months to get close-to-spec autodiscovery in Firefox, and realistically there’s maybe a week now before I’d miss the 1.5 boat.
Well the parts of a media type are fairly well defined: type/subtype and parameters. On the other hand the syntax of media type is not. It differs depending on context and specification. MIME Headers, HTTP Headers and the data URL Scheme for instance all specify different (although similar) syntax for media types. MIME even has a rather complicated RFC that handles characters outside of ASCII for MIME headers.
Phil: I would argue that this is not the place to look for a decision on that matter. Further, I would suggest that as both an implementor and a co-editor, your opinion on this matter carries a lot of weight. Get Involved - write a PACE.
Well, and once I thought about it, as an implementor with a deadline it doesn’t actually matter to me which way anyone including me decides: RSS is fixed in an ambiguous state no matter what Atom says, and if parameters are valid I want to accept them, but if they are invalid I want to accept them anyway, because they can’t lead to any false positives: “application/rss+xml; no really I meant text/html” is still application/rss+xml.
Meh. Doing time in the bowels of a browser’s bug database doesn’t produce many draconians. Misanthropists, yes, but draconians? If I do A I can expect m bug reports; if I do B I can expect n. The reporters in class α will be complete jerks, the reporters in class β will be apologetic about their needs. Bottom line: how can I minimize my own frustration?
Since I cannot find your (Sam) email address here, I will post this error as a comments. Delete at will
XML Parsing Error: not well-formed
Location: [link]
Line Number 13, Column 80:<link rel="openid.server" href="http://www.schtuff.com/?action=openid_server" /
Amusingly enough, the way my caching system works, your comment caused that page to be regenerated (to increase the comment count) wiping out my error.