[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-body-handling-03
From: Paul Kyzivat <pkyzivat at cisco.com>
> 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.
The behavior of 'handling' is defined in RFC 3459, as Eric points out.
But interestingly, 3459 gives no guidance in regard to
multipart/mixed. So I'd say that the I-D has freedom regarding
multipart/mixed.
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 partFrom sip-bounces at ietf.org Fri Sep 26 10:11:06 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 A09E23A686D;
Fri, 26 Sep 2008 10:11:06 -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 E07493A686D
for <sip at core3.amsl.com>; Fri, 26 Sep 2008 10:11:04 -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 SvmDTWMxSBeZ for <sip at core3.amsl.com>;
Fri, 26 Sep 2008 10:11:04 -0700 (PDT)
Received: from TheWorld.com (pcls4.std.com [192.74.137.84])
by core3.amsl.com (Postfix) with ESMTP id 0192A3A6800
for <sip at ietf.org>; Fri, 26 Sep 2008 10:11:03 -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 m8QH9Vv5026547
for <sip at ietf.org>; Fri, 26 Sep 2008 13:09:33 -0400
Received: from shell01.TheWorld.com (localhost [127.0.0.1])
by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id m8QH9VTB34568416
for <sip at ietf.org>; Fri, 26 Sep 2008 13:09:31 -0400 (EDT)
Received: (from worley at localhost)
by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id m8QH9QIu34937772;
Fri, 26 Sep 2008 13:09:26 -0400 (EDT)
Date: Fri, 26 Sep 2008 13:09:26 -0400 (EDT)
Message-Id: <200809261709.m8QH9QIu34937772 at shell01.TheWorld.com>
To: sip at ietf.org
From: Dale.Worley at comcast.net
In-reply-to: <48DAD56E.90204 at cisco.com> (pkyzivat at cisco.com)
References: <200809232006.m8NK619P33191730 at shell01.TheWorld.com> <48D97316.7070004 at cisco.com>
<200809242222.m8OMMsla33849134 at shell01.TheWorld.com>
<48DAD56E.90204 at cisco.com>
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>
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
From: Paul Kyzivat <pkyzivat at cisco.com>
> 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.
The behavior of 'handling' is defined in RFC 3459, as Eric points out.
But interestingly, 3459 gives no guidance in regard to
multipart/mixed. So I'd say that the I-D has freedom regarding
multipart/mixed.
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:
s 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.
If the processor doesn't know it doesn't support multipart/related, it
will assess the last component to see if it can process it. But the
processor may discover that it can't process the last component
(according to the rules for multipart/mixed), e.g., if the component
contains a component of a type that the processor doesn't understand
but the component has handling=required.
The key to my summary is that, in general, the processor must parse
the body and walk the body-part tree to obtain enough information to
determine which body-parts it will process. It is not a one-pass
process.
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
- 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.
If the processor doesn't know it doesn't support multipart/related, it
will assess the last component to see if it can process it. But the
processor may discover that it can't process the last component
(according to the rules for multipart/mixed), e.g., if the component
contains a component of a type that the processor doesn't understand
but the component has handling=required.
The key to my summary is that, in general, the processor must parse
the body and walk the body-part tree to obtain enough information to
determine which body-parts it will process. It is not a one-pass
process.
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