IETF Logo Mail Archive

Re: [Sip] Support for Multipart/MIME

Paul Kyzivat <pkyzivat@cisco.com> Fri, 18 May 2007 14:29 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 1Hp3SD-0007dO-0R; Fri, 18 May 2007 10:29:13 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hp3SB-0007dF-Co for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:29:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3SB-0007d7-30 for sip@ietf.org; Fri, 18 May 2007 10:29:11 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp3S9-0005aH-QS for sip@ietf.org; Fri, 18 May 2007 10:29:11 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2007 10:29:09 -0400
X-IronPort-AV: i="4.14,552,1170651600"; d="scan'208"; a="60603053:sNHT83669056"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4IET9c6006360; Fri, 18 May 2007 10:29:09 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4IESoC8025956; Fri, 18 May 2007 14:29:09 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:29:06 -0400
Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:29:05 -0400
Message-ID: <464DB831.8040607@cisco.com>
Date: Fri, 18 May 2007 10:29:05 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Support for Multipart/MIME
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>
In-Reply-To: <464AF68A.4010105@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2007 14:29:06.0010 (UTC) FILETIME=[E3B96BA0:01C79958]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=983; t=1179498549; x=1180362549; c=relaxed/simple; s=rtpdkim1001; 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:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>; bh=2p/ihFA3bfaV+VtuE561jvAkpB20nfN9J4NcQCykjuA=; b=B8PPrpXhSdE8jMNB/fUDlg8/s0syDuECUM0LjkdJJ1VwaC/Sn2gGxHzXRXjB+uTN5/BZqZ9V icu95y99Z1zIEv40Xb3bcQL6zmpgZG4rJZWoq9H/WI3uf1KC3HSTpDI/;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, 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

If we need any more motivation for this work, here is a quote from 
draft-ietf-mmusic-file-transfer-mech-02.

    The MMUSIC working group considered a few alternative
    approaches before deciding to use the encoding described in
    Section 6.  In particular, the working group looked at the MIME
    'external-body' type and the use of a single SDP parameter.

    A MIME 'external-body' could potentially be used to describe the file
    to be transfered.  In fact, many of the SDP parameters this
    specification defines are also supported by 'external-body' body
    parts.  The MMUSIC working group decided not to use 'external-body'
    body parts because a number of existing offer/answer implementations
    do not support multipart bodies.

I don't think we can hold that work hostage until there is better 
support for multipart. But that means there is one more thing that has 
been screwed around because of the lack of multipart support.

	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

v2.23.0 | Report a Bug | By Email