1. if you can parse MIME, you can handle multipart/mixed with only a single body part.
2. SIP has had MIME for a very long time. I know an implementation that handled multipart/mixed since 2001 ;-) 3. If your UAS can handle MIME, but not multipart/* with a single attachment, then it is your UAS *implementation* that is broken. 4. Saying "SHOULD NOT, MUST NOT, ... have a single body part in a multipart/*" is senseless. If it is MIME, it certainly MAY have a single body part. The correct answer is: Therefore, this document RECOMMENDS UAs NOT use a 'multipart' body when there is only one body part. This document RECOMMENDS UACs NOT nest one 'multipart/mixed' within another unless there is a need to reference the nested one (i.e., using the Content ID of the nested body part). This document RECOMMENDS UAs NOT nest one 'multipart/alternative' within another. One might want to put text in describing why we recommend that. Namely, it is wasteful in network resources and CPU resources as the recipient. To be clear, RFC 2046 allows a multipart to have a single sub-part, so if we do MIME, we allow single sub-parts. On 5/31/07 3:46 PM, "Christer Holmberg (JO/LMF)" <[EMAIL PROTECTED]> wrote: > > Hi, > >> I agree with Dan. >> >> I don't understand the use case in SIP of sending a Multipart >> with only one body. > > Again, I think I've seen INFOs and/or BYEs carrying ISUP informatio in > multipart, without any other body (unfortunately I have to use the word > "think", because I don't have any real examples in front of me :) > > But, I have nothing against saying that one SHOULD NOT (or even MUST > NOT) SEND it. But, I do think one should be prepared to RECEIVE such > messages, in order to be backward compatible with existing > implementations which may not be fully compliant the draft. > > And, regarding Dan's example: if a client is not able to handle > multipart carrying only SDP, I don't think it will be able to handle a > multipart carrying SDP and something else either - and we will have the > problem Francois presented earlier (the multipart, and the SDP innit, is > thrown away). > > Regards, > > Christer > > > > >>> -----Original Message----- >>> From: Dan Wing [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, May 31, 2007 10:38 >>> To: 'Christer Holmberg (JO/LMF)'; [email protected] >>> Cc: 'Gonzalo Camarillo (JO/LMF)'; Audet, Francois (SC100:3055) >>> Subject: RE: [Sip] MIME: MIME when only one body type >>> >>> >>>>> 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? >>> >>> Implementations may well be doing multipart/mixed and >> including only >>> one bodypart. I completely agree that might be happening. >>> >>>> Also, if a client is going to support multipart anyway, I >> don't see >>>> how it would harm interoperability. >>> >>> By doing that, you are teasing fate, and you aren't "being >>> conservative in what you send". Afterall, it's the >> receiver (not the >>> sender) of the MIME that may have difficulties. >>> >>>> I would be very surprised if a client supports MIME with multiple >>>> bodies, but not with a single body... >>> >>> Yep, but it isn't the client that I'm so worried about. I >> expect if >>> you sent a multipart containing one part (application/sdp), >> you would >>> find disasterous interoperability. >>> >>> -d >>> >> > > > _______________________________________________ > 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 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
