[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] draft-ietf-sip-body-handling-03
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 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'.
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):
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.
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 rulFrom sip-bounces at ietf.org Tue Sep 23 13:06:30 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 BC9A228C155;
Tue, 23 Sep 2008 13:06:30 -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 86FC13A6CFA
for <sip at core3.amsl.com>; Tue, 23 Sep 2008 13:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 xzIZszrnuXFK for <sip at core3.amsl.com>;
Tue, 23 Sep 2008 13:06:28 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146])
by core3.amsl.com (Postfix) with ESMTP id 8007C3A6CF7
for <sip at ietf.org>; Tue, 23 Sep 2008 13:06:28 -0700 (PDT)
Received: from shell.TheWorld.com (root at shell01.theworld.com [192.74.137.71])
by TheWorld.com (8.13.6/8.13.6) with ESMTP id m8NK63wS000893;
Tue, 23 Sep 2008 16:06:06 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1])
by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id m8NK61Vv33185669;
Tue, 23 Sep 2008 16:06:02 -0400 (EDT)
Received: (from worley at localhost)
by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id m8NK619P33191730;
Tue, 23 Sep 2008 16:06:01 -0400 (EDT)
Date: Tue, 23 Sep 2008 16:06:01 -0400 (EDT)
Message-Id: <200809232006.m8NK619P33191730 at shell01.TheWorld.com>
To: sip at ietf.org
From: Dale.Worley at comcast.net
Subject: [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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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 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'.
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):
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.
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)e (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.
Dale
_______________________________________________
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
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.
Dale
_______________________________________________
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