Hi, >>Chapter 3.2 of Gonzalo's draft says: >> >>"UAs should avoid unnecessarily nesting body parts. Therefore, UAs >>SHOULD NOT use a 'multipart' body when there is only one body part." >> >>However, chapter 5.1.1 of RFC2046 says: >> >>"NOTE: Experience has shown that a "multipart" media type with a >>single body part is useful for sending non-text media types." > >The only reason I could see it being useful for email was >when you're sending the message to a non-MIME-aware mail user >agent, and you included a MIME prologue: > > From: [EMAIL PROTECTED] > Content-Type: multipart/mixed; boundary=A > > You are reading this message with a mailer that doesn't understand > MIME. To review the attached content, use 'metamail'. > > --A > Content-Type: image/jpg > Content-Transfer-Encoding: base64 > > EJKF3849efjkej... > > --A-- > >>So, I think we need to add some words saying that it can be useful in >>some cases. > >Unless there is another case that it's useful for SIP, I think it could only harm interoperability.
Like I said, it may be used for transporting ISUP information. Maybe Francois has more information? Also, if a client is going to support multipart anyway, I don't see how it would harm interoperability. I would be very surprised if a client supports MIME with multiple bodies, but not with a single body... Regards, Christer _______________________________________________ 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
