[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-body-handling-03
Dale.Worley at comcast.net wrote:
1.
First, a complete nit: The title of section 6.2 is "UA Behavior to
Process 'multipart/alternative'", whereas it should be "UA Behavior to
Process 'multipart/related'".
2.
The handling of a multipart/mixed is 'required' if there is any
componentFrom sip-bounces at ietf.org Tue Sep 23 15:52:04 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 601483A6CFA;
Tue, 23 Sep 2008 15:52:04 -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 9C8333A6CF5
for <sip at core3.amsl.com>; Tue, 23 Sep 2008 15:52:03 -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 qx7jaeGu4H74 for <sip at core3.amsl.com>;
Tue, 23 Sep 2008 15:52:02 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
by core3.amsl.com (Postfix) with ESMTP id A8F243A6CFA
for <sip at ietf.org>; Tue, 23 Sep 2008 15:52:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,295,1220227200"; d="scan'208";a="46654631"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
by sj-iport-5.cisco.com with ESMTP; 23 Sep 2008 22:52:07 +0000
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m8NMq72s010887;
Tue, 23 Sep 2008 15:52:07 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
[128.107.191.100])
by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m8NMq7n2028448;
Tue, 23 Sep 2008 22:52:07 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 23 Sep 2008 15:52:07 -0700
Received: from [128.107.106.182] ([128.107.106.182]) by
xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 23 Sep 2008 15:52:06 -0700
Message-ID: <48D97316.7070004 at cisco.com>
Date: Tue, 23 Sep 2008 18:52:06 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Dale.Worley at comcast.net
References: <200809232006.m8NK619P33191730 at shell01.TheWorld.com>
In-Reply-To: <200809232006.m8NK619P33191730 at shell01.TheWorld.com>
X-OriginalArrivalTime: 23 Sep 2008 22:52:06.0898 (UTC)
FILETIME=[00FFF520:01C91DCF]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4043; t=1222210327;
x=1223074327; c=relaxed/simple; s=sjdkim3002;
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; bh=9N0qn8HKsNdiQPUecgrfBy3MJ5u9TgyDaYvmrg2yIys=;
b=dOS4QcO24vmF36zPbf+yoKhZRrAyGfPqla8mqHunwCYP53Ok0F1lCbCE6V
IzztZrXGZbn2012V8rzcv7BGirXtCLNXZ6jhrz8YfVtXiwnKbD2zancLcwdo
JnO7Ne6RTp;
Authentication-Results: sj-dkim-3; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/sjdkim3002 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:
1.
First, a complete nit: The title of section 6.2 is "UA Behavior to
Process 'multipart/alternative'", whereas it should be "UA Behavior to
Process 'multipart/related'".
2.
The handling of a multipart/mixed is 'required' if there is any
component whose h whose handling is 'required'. (My previous message stated
this incorrectly.)
This has the sense that handling is a "global"
property, in that any part is marked 'required' if any simple part
within it is marked 'required'.
What are you looking at to draw the above conclusion?
I didn't have that impression. I figured it was "local" as you describe
below.
This rule causes various problems. One problem is that the parts of a
multipart/alternative are supposed to have handling 'optional'
(although the handling value is ignored), which requires that all
components of a part that is a component of a multipart/alternative
must be 'optional'. This makes it impossible to convey the logic of
the following example and similar situations (which are likely to
happen in practice):
This is an area that also bothers me. Perhaps the handling of parts of a
multipart/alternative are irrelevant, as they are for multipart/related,
unless the recipient doesn't understand and treats it as
multipart/mixed. Of course, if a multipart/alternative is processed as a
multipart/mixed the result isn't likely to be good.
X: multipart/alternative
|
| A: multipart/mixed: A1 is required, A2 and A3 are optional
| |
| | A1: simple
| |
| | A2: simple
| |
| | A3: simple
|
| B: multipart/mixed: B1 is required, B2 and B3 are optional
| |
| | B1: simple
| |
| | B2: simple
| |
| | B3: simple
That is, in order to process A correctly, A1 must be understood, and
similarly for processing B correctly. But the recipient only needs to
understand A *or* B.
Its my understanding that there is an assumption that the alternatives
are increasingly rich, and it is assumed that you do the last one you
understand, but that then you also understand all the prior ones. (So in
effect you the last one before the first one you don't understand,
rather than doing the last one you do understand.)
According to the current draft, A1 and B1 must be marked 'required',
which implies that A and B must be marked 'optional'. That
contradicts the rule for multipart/alternative, but worse, it doesn't
express the logic of the situation.
A better rule (IMHO) would be that the 'handling' value is 'local',
that is, it tells whether understanding the component is necessary for
understanding the part that contains it. Leaving the specification of
whether the containing part needs to be understood to the containing
part's handling value, and those of the parts that contain it.
This fix requires amending the draft by removing the prescription of
how the handling of a multipart/mixed part is determined by the
handling of its components. I believe that (within the specifications
and implications of the draft) the draft's processing logic is not
modified.
3.
A processor that does not implement multipart/related is allowed to
process the part as if it was multipart/mixed. It's not clear that
there are *any* circumstances under which this will result in useful
results. The current draft hints at this, but the hint should
probably be strengthened into a warning that multipart/related should
not be used in any circumstance where the recipient is not constrained
by some mechanism to implement multipart/related.
This seems reasonable to me.
I would think that someone building a multipart/related should construct
it such that something reasonable happens if it is processed as a
multipart/mixed. But certainly it may be impossible to do that.
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
andling is 'required'. (My previous message stated
this incorrectly.)
This has the sense that handling is a "global"
property, in that any part is marked 'required' if any simple part
within it is marked 'required'.
What are you looking at to draw the above conclusion?
I didn't have that impression. I figured it was "local" as you describe
below.
This rule causes various problems. One problem is that the parts of a
multipart/alternative are supposed to have handling 'optional'
(although the handling value is ignored), which requires that all
components of a part that is a component of a multipart/alternative
must be 'optional'. This makes it impossible to convey the logic of
the following example and similar situations (which are likely to
happen in practice):
This is an area that also bothers me. Perhaps the handling of parts of a
multipart/alternative are irrelevant, as they are for multipart/related,
unless the recipient doesn't understand and treats it as
multipart/mixed. Of course, if a multipart/alternative is processed as a
multipart/mixed the result isn't likely to be good.
X: multipart/alternative
|
| A: multipart/mixed: A1 is required, A2 and A3 are optional
| |
| | A1: simple
| |
| | A2: simple
| |
| | A3: simple
|
| B: multipart/mixed: B1 is required, B2 and B3 are optional
| |
| | B1: simple
| |
| | B2: simple
| |
| | B3: simple
That is, in order to process A correctly, A1 must be understood, and
similarly for processing B correctly. But the recipient only needs to
understand A *or* B.
Its my understanding that there is an assumption that the alternatives
are increasingly rich, and it is assumed that you do the last one you
understand, but that then you also understand all the prior ones. (So in
effect you the last one before the first one you don't understand,
rather than doing the last one you do understand.)
According to the current draft, A1 and B1 must be marked 'required',
which implies that A and B must be marked 'optional'. That
contradicts the rule for multipart/alternative, but worse, it doesn't
express the logic of the situation.
A better rule (IMHO) would be that the 'handling' value is 'local',
that is, it tells whether understanding the component is necessary for
understanding the part that contains it. Leaving the specification of
whether the containing part needs to be understood to the containing
part's handling value, and those of the parts that contain it.
This fix requires amending the draft by removing the prescription of
how the handling of a multipart/mixed part is determined by the
handling of its components. I believe that (within the specifications
and implications of the draft) the draft's processing logic is not
modified.
3.
A processor that does not implement multipart/related is allowed to
process the part as if it was multipart/mixed. It's not clear that
there are *any* circumstances under which this will result in useful
results. The current draft hints at this, but the hint should
probably be strengthened into a warning that multipart/related should
not be used in any circumstance where the recipient is not constrained
by some mechanism to implement multipart/related.
This seems reasonable to me.
I would think that someone building a multipart/related should construct
it such that something reasonable happens if it is processed as a
multipart/mixed. But certainly it may be impossible to do that.
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