Martin Duerst wrote:
>> 5.
>> Publishers MUST NOT serve Atom feeds with a media type other than "application/atom+xml" (registered in this Section 8 of document) or one of the XML media types defined in RFC 3023 or its successor. In particular, "text/plain" is never an appropriate media type for an Atom feed. When retrieving an Atom feed served with a non-XML media type, clients MUST reject it as non-well-formed.
>
>
>We have no business stating this. I will serve Atom feeds as text/plain if I want them processed as text documents.
At which time I will claim that it's no longer an Atom feed, it just looks like one :-). The Atom spec should talk about Atom as Atom; that somebody might want to look at the Atom document as a text document, or even as a hex dump, isn't something we should be talking about.
I agree with Martin.
The feedvalidator currently declares content served as text/plain as invalid. I would very much like to keep this check, for a number of reasons. For now, I will simply state one:
text/plain can be used as part of a security breach. The feedvalidator can't stop such security breaches, but can discourage widescale deployment of feeds served in this manner. If we ever got to the point where there were widescale deployment of feeds served with text/plain, then consumers would essentially be forced to be liberal.
Note what I am not saying. I am not saying that applications other than the feedvalidator need to reject such feeds. Nor am I saying that you can't publish the same sequence of bytes that one would tend to find in an Atom feed with a content type of text/plain. What I am saying is that the Atom spec should allow consumers enough leeway to process such resources as non-feed (specifically, I would hope that they would process such resources as plain text).
- Sam Ruby
