[Sip] Support for Multipart/MIME

Cullen Jennings <fluffy@cisco.com> Mon, 30 April 2007 05:05 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 1HiO4x-0001d5-9B; Mon, 30 Apr 2007 01:05:39 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiO4w-0001b7-0h for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 01:05:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO4v-0001Zm-L5 for sip@ietf.org; Mon, 30 Apr 2007 01:05:37 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiO4v-0007PX-Ah for sip@ietf.org; Mon, 30 Apr 2007 01:05:37 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 29 Apr 2007 22:05:32 -0700
X-IronPort-AV: i="4.14,467,1170662400"; d="scan'208"; a="416905548:sNHT50011072"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3U55ViS012070; Sun, 29 Apr 2007 22:05:31 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l3U55LA9023582; Mon, 30 Apr 2007 05:05:30 GMT
In-Reply-To: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Date: Sun, 29 Apr 2007 22:04:45 -0700
To: IETF SIP List <sip@ietf.org>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3072; t=1177909531; x=1178773531; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Support=20for=20Multipart/MIME |Sender:=20; bh=WwYBS/A5oYYQFgThLpOVZH045rQSDBLpgVIORaXdJvA=; b=EX4Vtkdi7+Id26OKYhCakhRfgYP5xiyJtimxhYti9DvvGHUnCSv9zBFPbxmoBVI+7vWGXZ6I LKeAF0DzJzr8IhZNvbo/uxmMXzdXVV46OwtkDN158Weqo7IdwCmlW9DG;
Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc:
Subject: [Sip] Support for Multipart/MIME
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

The extensibility model of SIP and SDP is very powerful in most ways.  
It is often done by adding a new thing and if both sides understand  
it, they use it, and if they don't understand it, they use the other  
data in the messages that they both do understand and "fall back" to  
the old behavior. We can do this for headers, URI, and other places  
in SIP. We can do if for SDP attributes. However, there is one place  
were SIP is very lacking in it's ability to be upgraded in the  
future. This is around body extensibility.

The typical way to deal with extensibility of bodies is using MIME  
multipart. This allows a SIP message to cary more than one body and  
the receiver to select and use whichever ones it understands - This  
is all defined for sip except for one problem. It was not mandatory  
to implement and as you can see from the stats below, lots of UAs  
don't implement it.

I believe that sooner or later we will have to do this - it's pretty  
trivial to implement support for receiving multipart even if SDP is  
the only thing your UA knows how to handle.  Now we could argue about  
if emergency calls were the thing that absolutely required us to do  
this but my point is sooner or later we are going to need to deal  
with this - it has come up many times in the past.  I suspect it will  
only get more difficult over time to make this change.

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.

Cullen


On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:

> I'd like to point out one thing about this:
>
>> This is how they answered for multipart/mime:
>>     2% I break if someone sends me multipart/mime
>>    24% I pretend multipart/mime doesn't exist if someone sends it  
>> to me
>>    24% I ignore multipart/mime but will proxy it or hand it to my
>> application if it shows up
>>    10% I try to do something useful with multipart/mime I receive,
>> but I never send it
>>     4% I ignore multipart/mime that I receive, but I try to do
>> something useful with multipart/mime I send
>>    24% I try to do something useful with multipart/mime I send and
>> receive
>>    12% Other
>
> Moving forward, SIP UAs and proxies will be required to support
> location-conveyance (currently draft-ietf-sip-location- 
> conveyance-07) in
> order to support location for emergency calls (citizen to  
> authority, like
> 1-1-2 or
> 9-1-1).  -conveyance requires multipart support.
>
> The consequences of not supporting emergency call location will be  
> serious.
> I believe it is likely that there will eventually be regulatory  
> requirements
> to support emergency calls in some jurisdictions.  Upgrades to several
> components of today's infrastructure will be needed before this all  
> works,
> but stack vendors and UA developers should put multipart (and
> location-conveyance) on their development plans for next year at  
> the latest.
>
> Brian


_______________________________________________
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