Subject: Re: [Sip] MIME: MIME when only one body type

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

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-masked]> 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-masked]]
>>> Sent: Thursday, May 31, 2007 10:38
>>> To: 'Christer Holmberg (JO/LMF)'; [email-masked]
>>> 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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip