RE: [Sip] Support for Multipart/MIME

"Francois Audet" <audet@nortel.com> Wed, 16 May 2007 15:30 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLSA-0007Gz-IJ; Wed, 16 May 2007 11:30:14 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoLS9-0007Gu-7Z for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 11:30:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLS8-0007Gm-U7 for sip@ietf.org; Wed, 16 May 2007 11:30:12 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLS8-0008W8-HM for sip@ietf.org; Wed, 16 May 2007 11:30:12 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4GFU9225895; Wed, 16 May 2007 15:30:09 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Support for Multipart/MIME
Date: Wed, 16 May 2007 10:30:08 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com>
In-Reply-To: <464AF68A.4010105@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Support for Multipart/MIME
thread-index: AceXtFJHz89OmSEzQ+e6FULnhZLXNgAGq4TQ
References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com>
From: Francois Audet <audet@nortel.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a0534e6179a1e260079328e8b03c7901
Cc: sip@ietf.org, Dan Wing <dwing@cisco.com>, "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

My preference is one document. 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Wednesday, May 16, 2007 05:18
> To: Gonzalo Camarillo
> Cc: Audet, Francois (SC100:3055); sip@ietf.org; 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:dwing@cisco.com] Sent: Thursday, May 10, 
> >>>> 2007
> >>>> 09:19
> >>>> To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net
> >>>> Cc: sip@ietf.org
> >>>> 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 
> >>>> sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> >>>> sipping@ietf.org 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 
> >>> sip-implementors@cs.columbia.edu for questions on current sip Use 
> >>> sipping@ietf.org 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 
> >> sip-implementors@cs.columbia.edu for questions on current sip Use 
> >> sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip