[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Body handling draft
I think these changes generally look good. I'm now troubled by one thing:
In section 8.2 (UA Behavior to Set the 'handling' Parameter) the
following statement is repeated:
"If the handling of a 'multipart/*' body as a whole is required for
processing its enclosing body part or message" wherFrom sip-bounces at ietf.org Tue Nov 18 18:31:47 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 794EF3A6931;
Tue, 18 Nov 2008 18:31:47 -0800 (PST)
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 2B0043A691D
for <sip at core3.amsl.com>; Tue, 18 Nov 2008 18:31:46 -0800 (PST)
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 CMd-z32M95T7 for <sip at core3.amsl.com>;
Tue, 18 Nov 2008 18:31:44 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71])
by core3.amsl.com (Postfix) with ESMTP id C1A623A6931
for <sip at ietf.org>; Tue, 18 Nov 2008 18:31:44 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,628,1220227200"; d="scan'208";a="106650601"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-2.cisco.com with ESMTP; 19 Nov 2008 02:31:44 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAJ2ViWa024850;
Tue, 18 Nov 2008 18:31:44 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJ2ViBH007728;
Wed, 19 Nov 2008 02:31:44 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 18 Nov 2008 18:31:43 -0800
Received: from [10.21.70.168] ([10.21.70.168]) by xfe-sjc-212.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 18 Nov 2008 18:31:43 -0800
Message-ID: <49237A8C.9090109 at cisco.com>
Date: Tue, 18 Nov 2008 21:31:40 -0500
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
References: <492342D9.6060100 at ericsson.com>
In-Reply-To: <492342D9.6060100 at ericsson.com>
X-OriginalArrivalTime: 19 Nov 2008 02:31:43.0633 (UTC)
FILETIME=[F6142810:01C949EE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1545; t=1227061904;
x=1227925904; c=relaxed/simple; s=sjdkim1004;
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]=20Body=20handling=20draft
|Sender:=20; bh=/FJxYYXI0dgtHJSHXVS3Kcs3J2jNwhVy2UpbYaRCNXs=;
b=cv8j8UhKRPBsFHAQavA543CCN0azbBqYs7cxO1VpudZ/2qf8TvL+DD3LdL
SzHcPnFv2xh2i7h5WISI/rifd/JOGm+9kRwYH8uO3yl5uTc/ao+SDVo9p4NT
PfRiPQUSyi5vAiqEKR+J2XLouoYtkMeDtC9q0p/EwSSeKGA7fHCb4=;
Authentication-Results: sj-dkim-1; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/sjdkim1004 verified; );
Cc: sip <sip at ietf.org>
Subject: Re: [Sip] Body handling draft
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 think these changes generally look good. I'm now troubled by one thing:
In section 8.2 (UA Behavior to Set the 'handling' Parameter) the
following statement is repeated:
"If the handling of a 'multipart/*' body as a whole is required for
processing its enclosing body part or message" where * is {e * is {mixed,
alternative, related}.
For alternative and related this makes sense to me. But I don't know
what this means for 'mixed'. How would I know if I had to process this
*as a whole*, since there is no "as a whole" behavior of such a thing.
AFAIK the mixed container has no significance of its own - it is *only*
a container for its parts, each of which has its own significance.
I'm just trying to understand from an operational perspective how I
would make a decision between optional and required for a mixed body
part. The only things I can think of are:
- for some reason the mixed container is *referenced* from something.
E.g. a cid: uri referencing the content-id header in the mixed itself.
But I can't think of a reason to do that. It would seem to me that
if I need to do that then the parts must be related in some way,
so that I would be using multipart/related.
- one or more of the *contained* parts of the mixed are required,
and the container is being marked required to ensure that the
required contained parts will indeed be processed.
This seems the most sensible situation here.
Am I missing something that makes this easier to understand?
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
mixed,
alternative, related}.
For alternative and related this makes sense to me. But I don't know
what this means for 'mixed'. How would I know if I had to process this
*as a whole*, since there is no "as a whole" behavior of such a thing.
AFAIK the mixed container has no significance of its own - it is *only*
a container for its parts, each of which has its own significance.
I'm just trying to understand from an operational perspective how I
would make a decision between optional and required for a mixed body
part. The only things I can think of are:
- for some reason the mixed container is *referenced* from something.
E.g. a cid: uri referencing the content-id header in the mixed itself.
But I can't think of a reason to do that. It would seem to me that
if I need to do that then the parts must be related in some way,
so that I would be using multipart/related.
- one or more of the *contained* parts of the mixed are required,
and the container is being marked required to ensure that the
required contained parts will indeed be processed.
This seems the most sensible situation here.
Am I missing something that makes this easier to understand?
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