RE: [Sip] Support for Multipart/MIME

"Dan Wing" <dwing@cisco.com> Fri, 11 May 2007 00:37 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 1HmJ88-0002pp-5N; Thu, 10 May 2007 20:37:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmJ86-0002pk-VG for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 20:37:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJ86-0002pc-Ln for sip@ietf.org; Thu, 10 May 2007 20:37:06 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmJ86-0007Ka-7I for sip@ietf.org; Thu, 10 May 2007 20:37:06 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 17:37:05 -0700
X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="147402040:sNHT58734081"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B0b5vK011100; Thu, 10 May 2007 17:37:05 -0700
Received: from dwingwxp (dhcp-128-107-163-206.cisco.com [128.107.163.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B0ax20023951; Fri, 11 May 2007 00:37:03 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Paul Kyzivat' <pkyzivat@cisco.com>, 'Francois Audet' <audet@nortel.com>
Subject: RE: [Sip] Support for Multipart/MIME
Date: Thu, 10 May 2007 17:36:58 -0700
Message-ID: <115b01c79364$7f4d8d30$c4a36b80@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028
In-Reply-To: <4643B58A.3060407@cisco.com>
Thread-Index: AceTYW/Klv+XpbSFQYiKAzUiPWIulwAAeWJQ
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4434; t=1178843825; x=1179707825; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=CE2e6eMmkCTxRHpiPkEhBKWL7PhmcZ94aavDSaOybf0=; b=Bj6Lb2e8R8qiMHmzsMDxzjt/bL2KoCU2XY/euNxKIP5NZwrr62016usBLjVM7h3UmVpt/eA0 /dliff4MlMFQrovCrTH91nLsRZYfj0zrqsOnWJsv+IWYM8G6BZ769NzV;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: sip@ietf.org, "'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

...
> 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.

Yes, it's obscure, but that's alright.  There is the annoying
backward compatibility issue with lack of Content-Disposition,
too -- RFC3261 section 13.2.1, "Creating the Initial INVITE":

 >  If the Content-Disposition header field is missing, bodies of
 >  Content-Type application/sdp imply the disposition "session", while
 >  other content types imply "render".

...
> > 
> >   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.

That is sufficient justification to include multipart/alternative.

-d

> >   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