My preference is one document. > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 16, 2007 05:18 > To: Gonzalo Camarillo > Cc: Audet, Francois (SC100:3055); [email protected]; Dan Wing; > Christer Holmberg (JO/LMF) > Subject: Re: [Sip] Support for Multipart/MIME > > Hi Gonzalo, > > I guess the question is whether we want to write a document > specifically focused on Content-Disposition, or if we want to > combine work on that with work on specifying use of multipart. > > They aren't the same thing, but content-disposition becomes > more significant when there are multiple body parts, so there > is some justification for combining the work. > > Paul > > Gonzalo Camarillo wrote: > > Hi, > > > > yes, Paul and I talked about writing a draft to clarify a > few issues > > that relate to content dispositions in SIP a while ago. We > were quite > > busy at that point and did not have time to write it, but > maybe it is > > time to do it now. > > > > Cheers, > > > > Gonzalo > > > > > > Paul Kyzivat wrote: > >> > >> > >> Francois Audet wrote: > >>> I think we are on to something here. I believe that Paul > Kyzivat and > >>> Dan Wing have it right. > >>> > >>> What I'd like to see is something describing the following: > >>> > >>> - How to use Multipart/mixed > >>> > >>> I think Paul Kyzivat and Dan had some good explanation > in this thread > >>> about it. We should really make proper treatment of > multipart/mixed > >>> as mandatory > >>> as we can. This means, being able to understand parse > the nested > >>> MIME bodies that > >>> you DO support. > >>> At a miminum, an implementation should be able to find in a > >>> Multipart/mixed the SDP > >>> for example. We probably need also to write some > recommnedation on > >>> what happens if > >>> there is multiple SDPs in that multipart mixed. > >> > >> 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. > >> > >>> It's not pretty out there. I've seen implementations that don't > >>> even send 415 > >>> when receiving multipart/mixed: they just ignore the > payload, and > >>> believe > >>> it's an SDP-less INVITE. They then put an offer in the > response, > >>> which the > >>> real offerer believes is an answer. Then all hell breaks loose. > >>> > >>> Some of them do send 415, but without the supported > payload type in an > >>> Accept header in 415. > >>> > >>> > >>> - 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. > >> > >> The perfect example for that is MESSAGE with text/plain and > >> text/html, quite analogous to an email message. > >> > >>> 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 > >> > > >
_______________________________________________ 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
