* Antone Roundy <[EMAIL PROTECTED]> [2005-06-19 06:55]:
> Not all user-agents have a "MIME processor". Given the
> potential complexity and messiness of composite types, I'm
> opposed to leaving the door open for them, since they won't, I
> think, be needed by a significant proportion of Atom users.
Neither will all user agents have a Zip or tar decompressor.
Shouldn’t we ban application/x-tar and application/zip? What
about MSWord documents with embedded images and OLE objects?
Or PDF documents with images? All of these are conceptually
compound documents, and all of these are likely not to be
processible by most user agents. Shouldn’t these MIME types be
banned as well then?
On the other hand, some automated consumers that use Atom for
something completely different from content syndication, like
maybe logging agents, might not even have any support for
@type=('text','html','xhtml') at the application level, instead
only supporting some form of specific XML envelope document or
maybe a binary blob.
If someone wants to use Atom as an archival format for mailing
lists, and wants to stick message/rfc-822 into the atom:content,
why should the spec stop him?
If someone wants to use Atom as an envelope format for machine
consumption in a company-internal application, and he wants to
push multipart/* around, and he has control of the consumers and
can endow them with a MIME parser – then why should the Atom
format spec stop him?
Of course, the spec is not really stopping him as long as he has
control of all the end points, in which case he can just send
application/octet-stream, and can assume that his feed producers
mean something more specific than “non-descript blob of data” and
that his feed consumers know what to do about it – so instead of
stopping him, the spec has just made him put junk data in his
documents.
I think we’re shooting/have shot ourselves in the foot with this
restriction by disallowing a range of applications that could
have benefitted from Atom but won’t.
> This brings back bad memories of some really ugly data I saw
> coming out of Cyber Dog when I was working on Claris Emailer
> (Japanese)--a very convoluted and in fact buggy mess of
> multipart/alternative and multipart/mixed with lots of
> duplicated data which forced us to handle composite types
> incorrectly to avoid losing data.
How is that relevant? An Atom processor is not a mailer. It is
under no obligation whatesoever to treat a multipart/* or
message/* payload any differently from application/octet-stream.
Composite types should impose no particular duties upon the Atom
processor itself. If the application attached to it which
receives these payloads from the processor knows what to do with
multipart/*, then great. But if it doesn’t, then the Atom
processor certainly won’t care one way or the other.
Funnily enough, that’s exactly the same treatment that any other
known or unknown MIME type receives.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
