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 PROTECTED]>
--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 PROTECTED]>
--42
Content-Type: message/external-body;
access-type=mail-server
server="[EMAIL PROTECTED];
expiration="Fri, 14 Jun 2008 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID: <[EMAIL PROTECTED]>
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
