Sunday, June 19, 2005, 5:43:36 AM, Antone Roundy wrote:
> On Saturday, June 18, 2005, at 06:28 PM, David Powell wrote: >> Atom 0.3 multiparts forced a dubious and complex processing model on >> everyone wanting to process Atom documents. This problem was solved by >> their removal in the 03 to 07 drafts. >> >> The prohibition of composite types in the 08 draft (made many months >> later) is something quite different. > I haven't combed through the archives for messages to support this, but > had you asked me, I would have thought that we had explicitly decided > to disallow composite types, not just to get rid of 0.3's multipart > stuff. As Robert pointed out, it has been in all drafts since 03, only it was worded differently. My mistake. >> Composite types don't impose any >> change in the processing model of user-agents, they are just blobs >> that get passed to a MIME processor; there is no justification for >> restricting Atom payloads to a subset of the MIME type space. > Not all user-agents have a "MIME processor". Well they all do something with atom:content. They may choose only to allow the built in types: text, html, and xhtml to be processed; they may support a fixed set of additional MIME types: image/jpeg and image/gif; or they may support all MIME types by handing them off to another component (eg via an OBJECT tag, or just as a download link). composite types should be dealt with by processors in exactly the same way as any other unsupported MIME type. I'm not suggesting that Atom processors do anything with the composite, like select alternates or present attachments somehow. They should just treat it as they would any other exotic MIME type, just like HTTP does. It is unlikely that desktop aggregators would do anything special with composite types, but we aren't defining a protocol for desktop agregators, we are defining a document format and documenting what it means so that publishers and subscribers have a shared understanding of it. Allowing message/rfc822 would not cause any additional interpretability problems, so it is unsuitable for it to be banned with a MUST level constraint. > 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. 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. Yes, that's > just one anecdote. But it's an example of the kinds of ugliness that > can spill over from one bad implementation and mess things up for > everybody. Unless there's a use case that meets the so-called 80/20 > threshold, I'd be in favor of requiring publishers to keep things a > little simpler within Atom feeds. If somebody really needs composite > types, they can use an extension, and user-agent developers can > decide whether to support it. Mail user-agents need to unwrap and process composite types (the one I'm using now does it in a recursive panels and tabs way which works quite well). Atom user-agents don't need to unwrap and process composite types though. They should just treat them as data. If they don't support them themselves then they should just treat them as they would if they saw any other MIME type that they don't support. As I said in another reply, I'm not too bothered about us banning multipart/* because they aren't really standalone types, but we really shouldn't ban publishers from including message/rfc822 data, there isn't any good reason. -- Dave
