[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-body-handling-03
Dale.Worley at comFrom sip-bounces at ietf.org Mon Sep 29 10:55:09 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 A258B3A6AF4;
Mon, 29 Sep 2008 10:55:09 -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 0E1013A6AF4
for <sip at core3.amsl.com>; Mon, 29 Sep 2008 10:55:08 -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 ehGLWketKyjr for <sip at core3.amsl.com>;
Mon, 29 Sep 2008 10:55:07 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148])
by core3.amsl.com (Postfix) with ESMTP id E52B23A6981
for <sip at ietf.org>; Mon, 29 Sep 2008 10:55:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,333,1220227200"; d="scan'208";a="22619873"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2008 17:54:56 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8THsuPS012389;
Mon, 29 Sep 2008 13:54:56 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
[64.102.31.12])
by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8THsu6V026182;
Mon, 29 Sep 2008 17:54:56 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);
Mon, 29 Sep 2008 13:54:56 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by
xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 29 Sep 2008 13:54:55 -0400
Message-ID: <48E11673.2020108 at cisco.com>
Date: Mon, 29 Sep 2008 13:54:59 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Dale.Worley at comcast.net
References: <200809232006.m8NK619P33191730 at shell01.TheWorld.com> <48D97316.7070004 at cisco.com> <200809242222.m8OMMsla33849134 at shell01.TheWorld.com> <48DAD56E.90204 at cisco.com> <2A855E27-7EF3-48EE-B66C-EDDCFFEC27A5 at standardstrack.com> <48DC2E9B.4090607 at cisco.com>
<200809261709.m8QH9kUi35046697 at shell01.TheWorld.com>
In-Reply-To: <200809261709.m8QH9kUi35046697 at shell01.TheWorld.com>
X-OriginalArrivalTime: 29 Sep 2008 17:54:55.0995 (UTC)
FILETIME=[7B6E94B0:01C9225C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2241; t=1222710896;
x=1223574896; c=relaxed/simple; s=rtpdkim2001;
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]=20draft-ietf-sip-body-handling-03
|Sender:=20 |To:=20Dale.Worley at comcast.net;
bh=sPoWHeVVt0H7IEl2bK43WKB1qixgLROp2obeBxNJ5zE=;
b=Zch7Vxb4C/YsKJl7y488QL+gpTaDDtpaxSqrOrqhGoCyRGX7NpviP69iqI
zoqHxyh6MJhfn24u+6Q/IE4/qZcQ3XFNUpi/60FdlAGwz1+ZnIT5YkIOmu0d
lM/4Bf4K5n;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/rtpdkim2001 verified; );
Cc: sip at ietf.org
Subject: Re: [Sip] draft-ietf-sip-body-handling-03
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
Dale.Worley at comcast.net wrote:
From: Paul Kyzivat <pkyzivat at cisco.com>
> Section 12.1 makes it clear that for multipart/alternative, only the
> handling property for the selected alternative matters.
So you are saying that a multipart/alternative may have several parts
with handling=required, and that I only have to be capable of handling
the part I choose?
RFC 3459 uses multiparts in a somewhat different way that SIP does.
In SIP, the I-D suggests that components of a multipart/alternative
should have handling=optional and that the processor should ignore the
handling parameter:
The UA SHOULD also set the 'handling' parameter of all the
body part within the 'multipart/alternative' to 'optional'
(the receiver will process the body parts based on the
handling parameter of the 'multipart/alternative' body; the
receiver will ignore the handling parameters of the body
parts).
The receiver SHOULD ignore the handling parameters of the body
parts within the 'multipart/ alternative'.
Right. But the SHOULD without qualification suggests that somebody might
do otherwise, and we don't know under what circumstances that might
happen. So if somebody sets all the parts to handling=required, it seems
that the handling of the unselected parts will still be ignored.
Suppose I want to send a MESSAGE, and I require that some form of the
body be processed. I will offer it in two forms: text/enhanced and
text/html. How do I encode that?
C-T: multipart/alternative
C-D: render;handling=required
C-T: text/enhanced
C-D: render;handling=optional
===
C-T: text/html
C-D: render;handling=optional
or
C-T: multipart/alternative
C-D: render;handling=required
C-T: text/enhanced
C-D: render;handling=required
===
C-T: text/html
C-D: render;handling=required
And if I don't support either of those text types, what error do I
return? 415? In the first case it seems a little odd to return an error
if I selected a part that is optional.
And if I didn't require either part to be understood, would I just
change to handling=optional for the multipart/alternative itself?
_______________________________________________
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
cast.net wrote:
From: Paul Kyzivat <pkyzivat at cisco.com>
> Section 12.1 makes it clear that for multipart/alternative, only the
> handling property for the selected alternative matters.
So you are saying that a multipart/alternative may have several parts
with handling=required, and that I only have to be capable of handling
the part I choose?
RFC 3459 uses multiparts in a somewhat different way that SIP does.
In SIP, the I-D suggests that components of a multipart/alternative
should have handling=optional and that the processor should ignore the
handling parameter:
The UA SHOULD also set the 'handling' parameter of all the
body part within the 'multipart/alternative' to 'optional'
(the receiver will process the body parts based on the
handling parameter of the 'multipart/alternative' body; the
receiver will ignore the handling parameters of the body
parts).
The receiver SHOULD ignore the handling parameters of the body
parts within the 'multipart/ alternative'.
Right. But the SHOULD without qualification suggests that somebody might
do otherwise, and we don't know under what circumstances that might
happen. So if somebody sets all the parts to handling=required, it seems
that the handling of the unselected parts will still be ignored.
Suppose I want to send a MESSAGE, and I require that some form of the
body be processed. I will offer it in two forms: text/enhanced and
text/html. How do I encode that?
C-T: multipart/alternative
C-D: render;handling=required
C-T: text/enhanced
C-D: render;handling=optional
===
C-T: text/html
C-D: render;handling=optional
or
C-T: multipart/alternative
C-D: render;handling=required
C-T: text/enhanced
C-D: render;handling=required
===
C-T: text/html
C-D: render;handling=required
And if I don't support either of those text types, what error do I
return? 415? In the first case it seems a little odd to return an error
if I selected a part that is optional.
And if I didn't require either part to be understood, would I just
change to handling=optional for the multipart/alternative itself?
_______________________________________________
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