Re: [Sip] Support for Multipart/MIME

[Paul Kyzivat <[e-mail]>]

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