> -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 23, 2007 12:53 > To: Audet, Francois (SC100:3055); 'Gonzalo Camarillo' > Cc: 'Paul Kyzivat'; [email protected]; 'Christer Holmberg (JO/LMF)' > Subject: RE: [Sip] Support for Multipart/MIME > > Yes, I expect RFC3204's syntax and semantics work fine > between two implementations that implement RFC3204. > > My question if it the choice of multipart/mixed in RFC3204 > was correct or if multipart/related would have been more > appropriate for RFC3204. I have this question because the > QSIG (and ISUP) are directly related to the SDP, and the > QSIG/ISUP data provides additional information about that > outgoing PSTN call leg that assists it in being set up. > > My underlying question is what guidance we want to provide > for Gonzalo's document. If RFC3204's use of multipart/mixed > is what we want to do in SIP when there are bodyparts that > have a relationship with each other, then Gonzalo's document > will need to discourage use of multipart/related.
For Multipart/Related (as described in RFC 2387), I don't think it's applicable to 3204 as I think they would be independent. My reading of 2387 is that they depend on each other. This is not the case for 3204. They are not dependent. (And really, it's way too late to change 3204). But, if I interpret your question in a broader sense, I guess, the question is "Do we need to say anything about multipart/related?". I would extend it to parallel and digest... I guess we should. But I'm not sure what should be said. If we don't have a use case for them, I'd rather we don't encourage people to use it and create interop problems... _______________________________________________ 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
