Re: [Sip] Support for Multipart/MIME

Paul Kyzivat <pkyzivat@cisco.com> Mon, 30 April 2007 16:25 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 1HiYhB-0004Gk-Cw; Mon, 30 Apr 2007 12:25:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiYh8-0004Gf-Nq for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 12:25:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYh8-0004GX-EE for sip@ietf.org; Mon, 30 Apr 2007 12:25:46 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYh7-0000Nk-3l for sip@ietf.org; Mon, 30 Apr 2007 12:25:46 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2007 12:25:15 -0400
X-IronPort-AV: i="4.14,471,1170651600"; d="scan'208"; a="119893448:sNHT80952375154"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3UGPFqT017471; Mon, 30 Apr 2007 12:25:15 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UGPAlK004805; Mon, 30 Apr 2007 16:25:15 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 12:25:12 -0400
Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 12:25:12 -0400
Message-ID: <46361867.9010301@cisco.com>
Date: Mon, 30 Apr 2007 12:25:11 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] Support for Multipart/MIME
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com> <9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com> <200704301612.l3UGCwsM029162@dragon.ariadne.com>
In-Reply-To: <200704301612.l3UGCwsM029162@dragon.ariadne.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Apr 2007 16:25:12.0446 (UTC) FILETIME=[209BB1E0:01C78B44]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1171; t=1177950315; x=1178814315; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=oD+AN50crrjg0Kv8pnF3F4Gpc8T/LWCB+TJZU+f58V0=; b=Oq0UR86yJxsIpFZhzYw+QK42z4wV8c1M2ST4TO0gMohAUvvx1YRWeJcDu9J6HdrqeXGE52hc hD/QMptSG03t5e0GO/yM/AIRG7HtGXYEjESw1N4ReZORgJYj5ZTcQEC6;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org
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


Dale.Worley@comcast.net wrote:
>    From: Cullen Jennings <fluffy@cisco.com>
> 
>    I think the WG should consider an update to 3261 (likely done through  
>    the process Keith has proposed) that makes this multipart/MIME  
>    mandatory to implement.
> 
> I assume that the requirement is that if a message has a
> multipart/alternative body, and the UA is capable of understanding one
> part of the body, then it must be able to extract that part and use it
> to process the message.

While there is a place for multipart/alternative, I think the key 
requirement is that if there is a multipart/mixed then the UA should 
look within it for one or more parts that it would know how to handle if 
they were the only part in the body.

While doing this it also needs to process the handling= parameter on the 
Content-Disposition header. It can ignore parts with handling=optional, 
but must punt if handling=required on some part and it doesn't know how 
to handle it.

Writing down precisely what handling multipart means in sip would make a 
nice little draft. I expect there would be at least a bit of controversy 
about it.

	Paul


_______________________________________________
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