Subject: [Sip] SIP-body-handling Open Issue 1

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 20:14:37 +0900

Allowing multiple multipart/alternative sub-parts with the same content type
is very subtle.  The direct answer is, "no, one may not have identical
alternatives."

The subtlety is that one CAN have two multipart/alternative sub-parts with
the same Content-Type base.

For example, I can have (stealing liberally from RFC 2046):

     Content-Type: multipart/alternative; boundary=42
     Content-ID: <[email-masked]>

     --42
     Content-Type: text/plain; charset=us-ascii

     My badly formatted alternative.

     --42
     Content-Type: message/external-body; access-type=local-file;
                  name="/u/nsb/writing/rfcs/RFC-MIME.ps";
                  site="thumper.example.com";
                  expiration="Fri, 14 Jun 2008 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: <[email-masked]>

     --42
     Content-Type: message/external-body;
                  access-type=mail-server
                  server="[email-masked];
                  expiration="Fri, 14 Jun 2008 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: <[email-masked]>

     get RFC-MIME.DOC

     --42--

Notice that two of the alternatives are message/external-body with types
application/postscript.  However, the parameters of the
multipart/alternative Content-Type are different, rendering the
Content-Types different.

So, if the question is can I have two alternatives of type "mumble/foo", the
answer is, "Yes, you may.  For example, Content-Type: mumble/foo;param1=bar
and Content-Type: mumble/foo:param1=foobar are the same type but different
contents"  If the question is can I have two alternatives that are the
*identical* content type, like "mumble/foo;param1=bar" and "mumble/fool;
param1=bar", then the answer is, "No, you may not."

Just as in SIP, the MIME process needs to be able to determine if or how to
handle a given body part purely from inspecting the headers.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip