Hi, > - 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.
In my example earlier it was not about negotiting multiple alternatives of the same payload type. But, anyway, if we want to forbid app/sdp & app/sdp we need good technical justification for that, but my understanding is that Dan indicated he would be able to provide that. Regards, Christer > 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
