[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D Action:draft-ietf-sip-body-handling-03.txt
I took a look at this (actually just the diffs), and it looks fine.
I have one question after reading the additions about multipart/related:
There is talk about extensions that use multipart/related, and what they
must do. This implies an assumption that iFrom sip-bounces at ietf.org Tue Aug 12 16:28:11 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5BE863A6AD0;
Tue, 12 Aug 2008 16:28:11 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 930D33A6AD0
for <sip at core3.amsl.com>; Tue, 12 Aug 2008 16:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NCKfmRp8ENG4 for <sip at core3.amsl.com>;
Tue, 12 Aug 2008 16:28:08 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
by core3.amsl.com (Postfix) with ESMTP id 64C833A67DA
for <sip at ietf.org>; Tue, 12 Aug 2008 16:28:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,197,1217808000"; d="scan'208";a="139244086"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
by sj-iport-6.cisco.com with ESMTP; 12 Aug 2008 23:28:12 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7CNSBuH022073;
Tue, 12 Aug 2008 16:28:11 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
[64.102.31.102])
by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7CNSB5d006323;
Tue, 12 Aug 2008 23:28:11 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);
Tue, 12 Aug 2008 19:28:11 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by
xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 12 Aug 2008 19:28:10 -0400
Message-ID: <48A21CC2.5060906 at cisco.com>
Date: Tue, 12 Aug 2008 19:29:06 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
References: <20080808090001.570B63A6CC6 at core3.amsl.com>
In-Reply-To: <20080808090001.570B63A6CC6 at core3.amsl.com>
X-OriginalArrivalTime: 12 Aug 2008 23:28:10.0645 (UTC)
FILETIME=[15580C50:01C8FCD3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1348; t=1218583691;
x=1219447691; c=relaxed/simple; s=sjdkim2002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=pkyzivat at cisco.com;
z=From:=20Paul=20Kyzivat=20<pkyzivat at cisco.com>
|Subject:=20Re=3A=20[Sip]=20I-D=20Action=3Adraft-ietf-sip-b
ody-handling-03.txt |Sender:=20;
bh=dlFA1UR9pe2lYepjhD6kwkYBbLIUEVTyLBr4AB3ZaSk=;
b=x0MtvwkFcWjglYT6+fILtivxHrfDX2pE28PYlgWlXhFoorMHR4+LlTdZWj
8MrPElav9E752tjAHLlMQym2lRGE7E+t7xrszmA4ZIqgXTapA3+Sx2Ijj4NC
6jKh0LW9r2;
Authentication-Results: sj-dkim-2; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/sjdkim2002 verified; );
Cc: SIP IETF <sip at ietf.org>
Subject: Re: [Sip] I-D Action:draft-ietf-sip-body-handling-03.txt
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
I took a look at this (actually just the diffs), and it looks fine.
I have one question after reading the additions about multipart/related:
There is talk about extensions that use multipart/related, and what they
must do. This implies an assumption that it cannot be used *without* an
exception. Is that the case? If so, is it also the case for other kinds
of multipart?
My assumption is that, at least for multipart/mixed, no extension is
required. E.g. I can just put a multipart/mixed body in my INVITE, make
one body part be SDP, and others be anything I like, whether the
recipient can make use of them or not.
Similarly for multipart/alternative. I *think* I should be able to take
any request that currently expects a body part of some type, and put a
multipart/alternative in, with one part being the expected type, and one
or more other contained body parts containing what *I* consider to be
alternatives. E.g. a MESSAGE with a multipart/alternative containing
text/plain and text/html. And it shouldn't require any extension to
MESSAGE to support that. Right?
With multipart/related I am inclined to agree that it makes no sense
without some specification of what the collection is for.
Would it be good to put some words about what is/isn't required into the
document?
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
t cannot be used *without* an
exception. Is that the case? If so, is it also the case for other kinds
of multipart?
My assumption is that, at least for multipart/mixed, no extension is
required. E.g. I can just put a multipart/mixed body in my INVITE, make
one body part be SDP, and others be anything I like, whether the
recipient can make use of them or not.
Similarly for multipart/alternative. I *think* I should be able to take
any request that currently expects a body part of some type, and put a
multipart/alternative in, with one part being the expected type, and one
or more other contained body parts containing what *I* consider to be
alternatives. E.g. a MESSAGE with a multipart/alternative containing
text/plain and text/html. And it shouldn't require any extension to
MESSAGE to support that. Right?
With multipart/related I am inclined to agree that it makes no sense
without some specification of what the collection is for.
Would it be good to put some words about what is/isn't required into the
document?
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip