[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-body-handling-03
Eric Burger wrote:
Let's go back to where From sip-bounces at ietf.org Thu Sep 25 17:37:23 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 DE7783A686A;
Thu, 25 Sep 2008 17:37:23 -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 5BF603A686A
for <sip at core3.amsl.com>; Thu, 25 Sep 2008 17:37:22 -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=[AWL=0.000,
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 gH4gpjfkaTRg for <sip at core3.amsl.com>;
Thu, 25 Sep 2008 17:37:21 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70])
by core3.amsl.com (Postfix) with ESMTP id 1F1713A681B
for <sip at ietf.org>; Thu, 25 Sep 2008 17:37:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,309,1220227200"; d="scan'208";a="82990613"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-1.cisco.com with ESMTP; 26 Sep 2008 00:36:43 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8Q0ahDt008241;
Thu, 25 Sep 2008 17:36:43 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
[128.107.191.63])
by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8Q0ahAe023105;
Fri, 26 Sep 2008 00:36:43 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 25 Sep 2008 17:36:43 -0700
Received: from [128.107.102.130] ([128.107.102.130]) by
xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 25 Sep 2008 17:36:42 -0700
Message-ID: <48DC2E9B.4090607 at cisco.com>
Date: Thu, 25 Sep 2008 20:36:43 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Eric Burger <eburger at standardstrack.com>
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>
In-Reply-To: <2A855E27-7EF3-48EE-B66C-EDDCFFEC27A5 at standardstrack.com>
X-OriginalArrivalTime: 26 Sep 2008 00:36:42.0764 (UTC)
FILETIME=[F2889CC0:01C91F6F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8300; t=1222389403;
x=1223253403; 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]=20draft-ietf-sip-body-handling-03
|Sender:=20; bh=kfSciW9dBOdURKuT0r4QDhIAeUgVvsmkq0GRboDJfnY=;
b=ZuMhVf0jQJ4A8fLrWvZdExZkoTbdcefO0O1EGH3NRhYsiBemIOtWaUie2w
yUJ+Xwy7quscwTevVnuT6c9UCQDEzzqlZwfI/ht7et3hQkiazab6tDFUmuSX
IA/fNaTxIvbRm55fzvsHgS9ww9kC1QL7APjncZAPLGXLji93bk+Vw=;
Authentication-Results: sj-dkim-1; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/sjdkim1004 verified; );
Cc: SIP IETF <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
Eric Burger wrote:
Let's go back to where handlinghandling was really defined. RFC 3459 section
12.3 really does give guidence here:
Criticality only affects the outermost level of the message or, in
the case of multipart/alternative, the outermost level of the
selected alternative. Specifically, the receiving system ignores
criticality indicators in embedded body parts. This avoids the
situation of a forwarded message triggering or suppressing undesired
reporting. This simply implements the procedures described in [RFC
2183].
This doesn't exactly say what happens if you decide to start processing
the innards of a multipart/mixed. But it seems to suggest the "local"
interpretation that Dale is suggesting. Do you agree?
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?
Suppose I have a multipart/alternative with handling=requires, with
several parts that have handling=required, and one that is optional; and
I don't support the types of any of the parts. Can I select the one that
is optional and then do nothing with it, because it is optional? Will
that satisfy the requirement on the multipart/alternative?
BTW, the handling property of multipart/related parts DOES matter. This
is precisely where handling is most useful. The example in RFC 3459 is
the data and resource fork of a Macintosh file; it is highly likely for
the data fork to be REQUIRED whereas the resource fork may be OPTIONAL.
In the SIP world, although I would not suggest it, I could envision a
multipart/related caller description, where the REQUIRED part has some
identity information and the OPTIONAL part is a PNG of the caller. [In
the real world, the PNG would more likely be an optional part of the
caller description, but bear with me for the analysis.] Following the
rules of Section 12.1 of RFC 3459, the UAS has to understand the
identity part of the caller information, but can safely ignore the
picture part of the caller information.
Does this help, or did I miss the question?
I think the earlier comments do help, subject to my clarifying
questions. For this last point about mp/related, I wasn't asking about
it but your comments do suggest that changes in this document are called
for.
Thanks,
Paul
On Sep 24, 2008, at 6:03 PM, Paul Kyzivat wrote:
Dale.Worley at comcast.net wrote:
From: Paul Kyzivat <pkyzivat at cisco.com>
Dale.Worley at comcast.net wrote:
> 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'.
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.
From this:
7.2. UA Behavior to Set the 'handling' Parameter
[...]
If at least one of the body parts within a 'multipart/mixed' body has
a 'handling' value of 'required', the UA MUST set the 'handling'
parameter of the 'multipart/mixed' body to 'required'. If all the
body parts within a 'multipart/mixed' body have a 'handling' value of
'optional', the UA MUST set the 'handling' parameter of the
'multipart/mixed' body to 'optional'.
Oh, duh. Yeah, I agree this is a problem.
I agree the *useful* thing to do here is to have the handling be
"local" - only relevant if the container is being processed. That's if
we have the liberty to do that. There has been a desire not to diverge
from the mime/email interpretations of these things. I don't know what
is the case here.
> This rule causes various problems. was really defined. RFC 3459 section
12.3 really does give guidence here:
Criticality only affects the outermost level of the message or, in
the case of multipart/alternative, the outermost level of the
selected alternative. Specifically, the receiving system ignores
criticality indicators in embedded body parts. This avoids the
situation of a forwarded message triggering or suppressing undesired
reporting. This simply implements the procedures described in [RFC
2183].
This doesn't exactly say what happens if you decide to start processing
the innards of a multipart/mixed. But it seems to suggest the "local"
interpretation that Dale is suggesting. Do you agree?
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?
Suppose I have a multipart/alternative with handling=requires, with
several parts that have handling=required, and one that is optional; and
I don't support the types of any of the parts. Can I select the one that
is optional and then do nothing with it, because it is optional? Will
that satisfy the requirement on the multipart/alternative?
BTW, the handling property of multipart/related parts DOES matter. This
is precisely where handling is most useful. The example in RFC 3459 is
the data and resource fork of a Macintosh file; it is highly likely for
the data fork to be REQUIRED whereas the resource fork may be OPTIONAL.
In the SIP world, although I would not suggest it, I could envision a
multipart/related caller description, where the REQUIRED part has some
identity information and the OPTIONAL part is a PNG of the caller. [In
the real world, the PNG would more likely be an optional part of the
caller description, but bear with me for the analysis.] Following the
rules of Section 12.1 of RFC 3459, the UAS has to understand the
identity part of the caller information, but can safely ignore the
picture part of the caller information.
Does this help, or did I miss the question?
I think the earlier comments do help, subject to my clarifying
questions. For this last point about mp/related, I wasn't asking about
it but your comments do suggest that changes in this document are called
for.
Thanks,
Paul
On Sep 24, 2008, at 6:03 PM, Paul Kyzivat wrote:
Dale.Worley at comcast.net wrote:
From: Paul Kyzivat <pkyzivat at cisco.com>
Dale.Worley at comcast.net wrote:
> 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'.
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.
From this:
7.2. UA Behavior to Set the 'handling' Parameter
[...]
If at least one of the body parts within a 'multipart/mixed' body has
a 'handling' value of 'required', the UA MUST set the 'handling'
parameter of the 'multipart/mixed' body to 'required'. If all the
body parts within a 'multipart/mixed' body have a 'handling' value of
'optional', the UA MUST set the 'handling' parameter of the
'multipart/mixed' body to 'optional'.
Oh, duh. Yeah, I agree this is a problem.
I agree the *useful* thing to do here is to have the handling be
"local" - only relevant if the container is being processed. That's if
we have the liberty to do that. There has been a desire not to diverge
from the mime/email interpretations of these things. I don't know what
is the case here.
> 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.
The current draft states that the handling of components of a
multipart/alternative are to be ignored:
7.3. UA Behavior to Process 'multipart/alternative'
The receiver of 'multipart/alternative' body MUST process the body
based on its handling parameter. The receiver SHOULD ignore the
handling parameters of the body parts within the 'multipart/
alternative'.
And that seems to be completely correct; which component should be
processed is completely determined by other factors.
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.
I don't see that that is required at all. It would be devilishly
difficult to implement.
I just reviewed the def of multipart/alternative in RFC 2045, and I
agree your interpretation is right. In fact, choosing the last
supported one isn't required, but its more of a suggestion.
> 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.
I expect that in practice, every situation where multipart/related is
used is protected by some extension mechanism to ensure that the
recipient understands it. That's the case now with "resource list
events", with "Require: eventlist".
That would certainly be wise. I guess you could dispense with that
*if* you can structure it so that processing it as a mixed is
tolerable. Hard to predict if anybody would ever do that, but we
needn't forbid it.
The key here for anyone sending *any* multipart/XYZ is that anyone
capable of processing a multipart/mixed will consider themselves
capable of supporting multipart/XYZ, as a multipart/mixed.
So, creating a multipart/alternative, where the contained parts are:
- text/plain
- multipart/mixed
- multipart/related
isn't going to be very helpful. Anybody who supports multipart/mixed
will process the last part, not the second.
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
_______________________________________________
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
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.
The current draft states that the handling of components of a
multipart/alternative are to be ignored:
7.3. UA Behavior to Process 'multipart/alternative'
The receiver of 'multipart/alternative' body MUST process the body
based on its handling parameter. The receiver SHOULD ignore the
handling parameters of the body parts within the 'multipart/
alternative'.
And that seems to be completely correct; which component should be
processed is completely determined by other factors.
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.
I don't see that that is required at all. It would be devilishly
difficult to implement.
I just reviewed the def of multipart/alternative in RFC 2045, and I
agree your interpretation is right. In fact, choosing the last
supported one isn't required, but its more of a suggestion.
> 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.
I expect that in practice, every situation where multipart/related is
used is protected by some extension mechanism to ensure that the
recipient understands it. That's the case now with "resource list
events", with "Require: eventlist".
That would certainly be wise. I guess you could dispense with that
*if* you can structure it so that processing it as a mixed is
tolerable. Hard to predict if anybody would ever do that, but we
needn't forbid it.
The key here for anyone sending *any* multipart/XYZ is that anyone
capable of processing a multipart/mixed will consider themselves
capable of supporting multipart/XYZ, as a multipart/mixed.
So, creating a multipart/alternative, where the contained parts are:
- text/plain
- multipart/mixed
- multipart/related
isn't going to be very helpful. Anybody who supports multipart/mixed
will process the last part, not the second.
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
_______________________________________________
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