RE: [Sip] Support for Multipart/MIME

> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com] 
> Sent: Friday, May 11, 2007 9:12 AM
> To: Paul Kyzivat
> Cc: Dan Wing; Christer Holmberg (JO/LMF); 
> Dale.Worley@comcast.net; sip@ietf.org
> 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:pkyzivat@cisco.com] 
> > Sent: Thursday, May 10, 2007 17:15
> > To: Audet, Francois (SC100:3055)
> > Cc: Dan Wing; Christer Holmberg (JO/LMF); 
> > Dale.Worley@comcast.net; sip@ietf.org
> >
> > 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip