> -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: Friday, May 11, 2007 9:12 AM > To: Paul Kyzivat > Cc: Dan Wing; Christer Holmberg (JO/LMF); > [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip] Support for Multipart/MIME > > I think what we need to do is describe what you are > explaining here, but > we need to make sure that we don't introduce backward compatibility > problems. > > (e.g., maybe if Content-disposition: session is not present, it is > assumed to mean session?)
RFC3261 says that already, on page 80: If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition "session", while other content types imply "render". -d > > -----Original Message----- > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 10, 2007 17:15 > > To: Audet, Francois (SC100:3055) > > Cc: Dan Wing; Christer Holmberg (JO/LMF); > > [EMAIL PROTECTED]; [email protected] > > > > Subject: Re: [Sip] Support for Multipart/MIME > > 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. _______________________________________________ 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
