Re: [Sip] Support for Multipart/MIME

[Gonzalo Camarillo <[e-mail]>]

Hi,

yes, Paul and I talked about writing a draft to clarify a few issues 
that relate to content dispositions in SIP a while ago. We were quite 
busy at that point and did not have time to write it, but maybe it is 
time to do it now.

Cheers,

Gonzalo


Paul Kyzivat wrote:
> 
> 
> Francois Audet wrote:
>> I think we are on to something here. I believe that Paul Kyzivat and Dan
>> Wing have it
>> right.
>>
>> What I'd like to see is something describing the following:
>>
>> - How to use Multipart/mixed
>>
>>   I think Paul Kyzivat and Dan had some good explanation in this thread
>> about it.   We should really make proper treatment of multipart/mixed 
>> as mandatory
>> as we can.   This means, being able to understand parse the nested 
>> MIME bodies that
>> you DO support.
>>   At a miminum, an implementation should be able to find in a
>> Multipart/mixed the SDP
>>   for example. We probably need also to write some recommnedation on
>> what happens if
>>   there is multiple SDPs in that multipart mixed.
> 
> I would like to bring up something that isn't discussed much: 
> Content-Disposition. I brought it up earlier in this thread for a 
> slightly different reason.
> 
> One *should not* look for a particular body part of interest solely 
> based on the Content-Type. Both the content type and the content 
> disposition need to be correct. For instance, a body part with content 
> type of application/sdp should not be considered an offer or answer 
> unless the content-disposition is "session". (This is confused because 
> there are are also defaulting rules for content-disposition.)
> 
> *In principle* you could have a multipart/mixed that had to parts, both 
> with content-type of application/sdp. This could be quite legal if only 
> one of them had content-disposition of "session" and the other had some 
> other content-disposition. It would be sufficient for the other to have 
> "Content-Disposition:foo;handling=optional".
> 
> I realize this is obscure, and it isn't likely that anyone will be 
> including an sdp body part that isn't intended to be an offer or answer. 
> But we are writing the specs here, and we ought to be complete and 
> precise about it.
> 
>>   It's not pretty out there. I've seen implementations that don't even
>> send 415
>>   when receiving multipart/mixed: they just ignore the payload, and
>> believe
>>   it's an SDP-less INVITE. They then put an offer in the response, which
>> the
>>   real offerer believes is an answer. Then all hell breaks loose.
>>
>>   Some of them do send 415, but without the supported payload type in an
>> Accept   header in 415.
>>
>>
>> - Multipart/alternative
>>
>>   I agree with Dan that using Multipart/alternative in the way that was
>> described
>>   in draft-jennings-sipping-multipart section 5 is in fact harmful.
>> Especially now that we
>>   are defining capability negotiation. Section 6 would be OK, but now
>> that SDPng is gone,
>>   it's irrelevant.
>>
>>   What we really need to say is that multipart/alternative may be used
>> only when we
>>   are using alternative payload types for the same information. For
>> example, text/html and   text/xml or whatever. It would be applicable 
>> if one day we re-created
>> another SDPng   for example.
> 
> The perfect example for that is MESSAGE with text/plain and text/html, 
> quite analogous to an email message.
> 
>>   Section 3.1 explains this relatively well, but is restricted to Offers
>> (for which we have
>>   no use cases anymore). I think it should instead talk about other
>> examples (e.g.,
>>   text/html, text/xml, or maybe some example with pictures).
>>
>>   I really believe section 5 goes against the spririt of section 3.1
>> (specifically, of
>>   the quote of RFC 2046). What it really has it two application/sdp (one
>> of them is   encrypted inside a application/pkcs7mime), but really 
>> it's still two
>> application/sdp
>>
>>   But we should make it clear that it is NOT for negotiating multiple
>> alternatives of   the same payload type, in particular, not for 
>> application/sdp &
>> application/sdp.
>>   If we decide to go forward, I'd be happy to help too.
> 
> I don't have time to take authorship of the document, but I too can 
> contribute some text.
> 
>     Paul
> 
>>> -----Original Message-----
>>> From: Dan Wing [mailto:[e-mail]] Sent: Thursday, May 10, 2007 
>>> 09:19
>>> To: 'Christer Holmberg (JO/LMF)'; [e-mail]
>>> Cc: [e-mail]
>>> Subject: RE: [Sip] Support for Multipart/MIME
>>>
>>>>> I have become convinced, through my efforts with RTPSEC, that 
>>>>> multipart/alternative is harmful if it contains multiple SDP parts.
>>>> Again, I am not in a position to disagree with you ,but is that 
>>>> harmfulness documented somewhere?
>>> Nope.  If we're going to move multipart/* forward in SIP, though, 
>>> I'll be happy to write that section.
>>>
>>> -d
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use 
>>> [e-mail] for questions on current sip Use 
>>> [e-mail] for new developments on the application of sip
>>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments on the application of sip
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 



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