Subject: Conflict between the AtomPub multipart/related and composite content proposals

From: "Brian Smith" <[email-masked]>
Date: Wed, 1 Oct 2008 08:45:26 -0500

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