Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

On Sat, Jun 18, 2005 at 10:43:36PM -0600, Antone Roundy wrote: > > 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 proportio

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

* Graham <[EMAIL PROTECTED]> [2005-06-18 21:50]: > The better way to do this is to use > to reference the messages. Is there any verbiage that would preclude a data: URI with a multipart payload in atom:link? Regards, -- Aristotle Pagaltzis //

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

* 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 use

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

Sunday, June 19, 2005, 5:07:01 AM, you wrote: >> The prohibition of composite types in the 08 draft (made many months >> later) > Um, no. One of the drafts reworded the requirement in terms of the new > MIME draft. Previously, the draft cited RFC2045's "discrete type". > From format-03: >

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

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