Brian Smith wrote: > My proposal is to create a new standards-track RFC that > updates RFC 4287. The RFC would say only this > (plus the standard RFC boilerplate text): > > ... > > 1. All MIME types are allowed in atom:content > > The restriction on atom:content's type > attribute "but MUST NOT be a composite type" > from section 4.1.3 in RFC 4287 is removed. > There are now no restrictions on the type of > content allowed in atom:content. > > The rules for processing atom:content remain > exactly as specified in Section 4.1.3.3 > of [RFC4287]. In particular, when the > atom:content element contains content with > a composite MIME type, that content must be > encoded in Base64 as specified in step #6 of > that section.
I got two positive responses and nobody objected. I was hoping for more feedback, but I guess I will press on with this. One issue that I did not mention in my previous message is that the current multipart/alternate proposal doesn't compose well with this proposal. The multipart/alternate proposal uses the Content-Type of the POST request to decide when to unpack the request. As was mentioned in the earlier discussion of the multipart/alternate draft, this conflicts with any other use for posting multipart/related content to a collection. For example, I have applications that post multipart/alternate content to collections so that the multi-part message can be stored as-is in the collection as a media resource. It would be better for the multipart proposal(s) to avoid overloading the Content-Type header for its purposes. A new request header or a link to a new resource that does the unpacking could be used instead. Regards, Brian
