* 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.
Well, you can pass them around by reference with [EMAIL PROTECTED] I think.