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: > "Failing that, it MUST be a MIME media type [RFC2045] in which, to use > the terminology of Section 5 of [RFC2045], the top level is a discrete > type." > We had to, you know, make an editorial change because the new MIME > draft doesn't use the term "discrete type" anymore. Ah, thanks. I don't know how I missed that. OK, process-objection withdrawn, but the problem that Mark highlighted still exists: Atom prohibits message/rfc822; I don't think that it should. I'd prefer the solution to be to lift the restriction completely, than to only lift the restriction for remote content. It is worth looking what HTTP says about composite types in RFC 2616: > In general, HTTP treats a multipart message-body no differently than > any other media type: strictly as payload. message/rfc822 isn't mentioned at all by HTTP, and is therefore also treated as just data. It is pretty commonly used too, for both email (eg: Download from webmail interfaces), and for MHTML content (such as the format that can be saved by Word 2000 (I think?)). To be honest, I'm not bothered about mulipart/* being banned. I don't think that it is particularly useful, but I still don't think that we need to ban it. What if some really useful multipart/* type gets defined in future - something on the lines of multipart/appledouble [1], where the multipart is a blob of content that can be passed to helper applications as a discrete unit. message/rfc822 is definitely useful though. There is no reason to ban it, certainly not with a MUST level constraint. Conceptually it is no more composite than an application/msword document is composite. [1] http://www.iana.org/assignments/media-types/multipart/appledouble -- Dave
