... > 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.
Yes, it's obscure, but that's alright. There is the annoying backward compatibility issue with lack of Content-Disposition, too -- RFC3261 section 13.2.1, "Creating the Initial INVITE": > If the Content-Disposition header field is missing, bodies of > Content-Type application/sdp imply the disposition "session", while > other content types imply "render". ... > > > > 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. That is sufficient justification to include multipart/alternative. -d > > 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:[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 > > _______________________________________________ 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
