RE: [Sip] Support for Multipart/MIME

"Dan Wing" <dwing@cisco.com> Wed, 23 May 2007 20:24 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 1HqxO4-0000XY-6e; Wed, 23 May 2007 16:24:48 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqxO1-0000P8-Fe for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 16:24:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxO1-0000Ox-5v for sip@ietf.org; Wed, 23 May 2007 16:24:45 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqxNz-0002S8-T2 for sip@ietf.org; Wed, 23 May 2007 16:24:45 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 13:24:43 -0700
X-IronPort-AV: i="4.14,571,1170662400"; d="scan'208"; a="156743639:sNHT42214149"
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 l4NKOhtv031658; Wed, 23 May 2007 13:24:43 -0700
Received: from dwingwxp ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4NKOg06025608; Wed, 23 May 2007 20:24:42 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Francois Audet' <audet@nortel.com>, 'Gonzalo Camarillo' <Gonzalo.Camarillo@ericsson.com>
Subject: RE: [Sip] Support for Multipart/MIME
Date: Wed, 23 May 2007 13:24:42 -0700
Message-ID: <0bb501c79d78$6599e7d0$c6f0200a@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: <1ECE0EB50388174790F9694F77522CCF10955027@zrc2hxm0.corp.nortel.com>
Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAADEa9AAAIzN4A==
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1440; t=1179951883; x=1180815883; c=relaxed/simple; s=sjdkim7002; 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=x418epCfEZwxBiuqsa4IcYObzs+f6ykiblnvzgqb5/E=; b=iG+mm5KVOMjkH2iT6+4fZ5w2pDNMGOvz8Ry5eNm49TptyPjWWSoFwHXHRLdqkHOqHljS7cJP 6kT5ziSPyX9b/IPcv/FakH4bz6vFZDqxrBbziu9WrSLJjBZpVDe1LqrI;
Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: sip@ietf.org, 'Paul Kyzivat' <pkyzivat@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

> For Multipart/Related (as described in RFC 2387), I
> don't think it's applicable to 3204 as I think they would be 
> independent. My reading of 2387 is that they depend on each
> other.
>
> This is not the case for 3204. They are not dependent.

In RFC3204, the QSIG or ISUP parts do not appear to have any meaning without
the SDP.  Or do they?  For example, is it meaningful for me to send an
INVITE that has only the QSIG part (and no SDP)?

> (And really, it's way too late to change 3204).

Even if consensus were to be formed that there was a mistake?  Obviously no
such consensus has been formed, but I would like to have the discussion.

If we do consider it acceptable to change RFC3261's requirements around MIME
multipart support, I suggest it is reasonable to analyze what we may have
done wrong elsewhere around MIME with SIP.

> But, if I interpret your question in a broader sense, I guess,
> the question is "Do we need to say anything about
> multipart/related?". I would extend it to parallel and digest...

And external-body, and all the other parts.  Yes, that is my underlying
question in light of Gonzalo's document and Cullen's stated desire for the
SIP community to document multipart support.

> I guess we should. But I'm not sure what should be said. 
> If we don't have a use case for them, I'd rather we don't encourage
> people to use it and create interop problems...

-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