* John Panzer <[EMAIL PROTECTED]> [2005-10-13 18:45]: > If I recall, I believe this is because some people wanted to be > able to package multiple pieces of content together in a single > entry, and other people did not want to have to imply a > requirement for MIME multipart parsing as pat of the Atom > format specification.
And in retrospect, I think this was a mistake. F.ex. a while ago we had someone asking why he isn’t able to publish mailing list archives as a feed with entries containing the original message as a message/rfc822 payload, and indeed there’s no good reason he can’t. He just can’t. (This would have been a nice use case: stick the original message into atom:content and put a version rendered as HTML into atom:summary. I have to say I am liking this atom:summary/atom:content dichotomy more and more with every passing day.) The right thing, I *think*, would have been for Atom Format to say that an Atom processor MAY decode envelopes (translation: don’t hold your breath), and for Atom Protocol to say the server MUST NOT decode envelopes (translation: if I ship a message/rfc822 payload, the server simply stores it as such). As is, the only option is to stick the blob into an enclosure, inlined though the backdoor by using a data: URI. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
