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. 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. 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. > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 10, 2007 09:19 > To: 'Christer Holmberg (JO/LMF)'; [EMAIL PROTECTED] > Cc: [email protected] > 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 > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
