[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D Action:draft-ietf-sip-body-handling-03.txt
Hi Paul,
Section 9 of the draft contains the following text:
Authors of SIP extensions making use of 'multipart/related' bodies
have to explicitly address the handling of the disposition types of
the body parts within the 'multipart/related' body. Authors wishing
to make use of 'multipart/related' bodies should keep in mind that
UAs that do not understand 'multipart/related' will treat it as
'multipart/mixed'.
Let me know whether or not you think this text is enough and, if not,
please propose the additions, removals, or modifications to the current
text that you think are needed.
Thanks,
Gonzalo
Paul Kyzivat wrote:
> 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 From sip-bounces at ietf.org Tue Sep 2 11:20:14 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2F4003A6ACD;
Tue, 2 Sep 2008 11:20:14 -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 88D3C3A68F9
for <sip at core3.amsl.com>; Tue, 2 Sep 2008 11:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 rdJZm4DQNUp4 for <sip at core3.amsl.com>;
Tue, 2 Sep 2008 11:20:11 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
by core3.amsl.com (Postfix) with ESMTP id 6CFCE3A680A
for <sip at ietf.org>; Tue, 2 Sep 2008 11:20:11 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
009D320B68; Tue, 2 Sep 2008 20:20:06 +0200 (CEST)
X-AuditID: c1b4fb3c-ae0cebb0000015b5-8d-48bd83d62871
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
D8E5A20B62; Tue, 2 Sep 2008 20:20:06 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 2 Sep 2008 20:20:06 +0200
Received: from [131.160.126.4] ([131.160.126.4]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 2 Sep 2008 20:20:06 +0200
Message-ID: <48BD83D6.4090202 at ericsson.com>
Date: Tue, 02 Sep 2008 21:20:06 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat at cisco.com>
References: <20080808090001.570B63A6CC6 at core3.amsl.com>
<48A21CC2.5060906 at cisco.com>
In-Reply-To: <48A21CC2.5060906 at cisco.com>
X-OriginalArrivalTime: 02 Sep 2008 18:20:06.0321 (UTC)
FILETIME=[8680CA10:01C90D28]
X-Brightmail-Tracker: AAAAAA==
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi Paul,
Section 9 of the draft contains the following text:
Authors of SIP extensions making use of 'multipart/related' bodies
have to explicitly address the handling of the disposition types of
the body parts within the 'multipart/related' body. Authors wishing
to make use of 'multipart/related' bodies should keep in mind that
UAs that do not understand 'multipart/related' will treat it as
'multipart/mixed'.
Let me know whether or not you think this text is enough and, if not,
please propose the additions, removals, or modifications to the current
text that you think are needed.
Thanks,
Gonzalo
Paul Kyzivat wrote:
> 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 kiother 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
nds
> 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