[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Comments on draft-ietf-sip-body-handling-02

Either it's MIME or it's not.

By the time we work this out, SDP-NG might be real :-)

On Sep 29, 2008, at 11:43 AM, Paul Kyzivat wrote:


I agree it would be straightforward to define a rule that says one  
must recursively unwrap all multipart/mixed bodies in order to find  
other parts to process. But we ought to think if we really want to  
do that.



Potentially this could introduce a lot of extra processing. Its  
especially a problem if there are middle boxes that want to process  
SDP. They don't know if a given message contains SDP at all. And  
they perhaps don't want to process anything *except* SDP. But they  
will be forced to recursively open all the mixed parts to determine  
if there is an sdp for them.


(Or maybe this is a good thing because it will discourFrom sip-bounces at ietf.org  Mon Sep 29 12:00:42 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 D03133A6B68;
	Mon, 29 Sep 2008 12:00:42 -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 BB8D13A6B68
	for <sip at core3.amsl.com>; Mon, 29 Sep 2008 12:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499

X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 
	BAYES_00=-2.599]

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 OI+s5s0cK8da for <sip at core3.amsl.com>;
	Mon, 29 Sep 2008 12:00:39 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
	[66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id C64F83A6B41
	for <sip at ietf.org>; Mon, 29 Sep 2008 12:00:26 -0700 (PDT)
Received: from [75.68.119.237] (port=61399 helo=[192.168.15.100])
	by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.68) (envelope-from <eburger at standardstrack.com>)
	id 1KkNyl-0000Bl-LQ; Mon, 29 Sep 2008 12:00:20 -0700
Message-Id: <1B19D41C-45C9-4784-A2AD-FA43A1623A80 at standardstrack.com>
From: Eric Burger <eburger at standardstrack.com>
To: Paul Kyzivat <pkyzivat at cisco.com>
In-Reply-To: <48E0F79B.8090402 at cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 29 Sep 2008 15:00:21 -0400
References: <5D1A7985295922448D5550C94DE2918002196DCC at DEEXC1U01.de.lucent.com>	<48898492.7010601 at ericsson.com>	<5D1A7985295922448D5550C94DE2918002196FF7 at DEEXC1U01.de.lucent.com>	<4889F09B.8050407 at cisco.com>
	<200809262108.m8QL8fpj34800452 at shell01.TheWorld.com>
	<48E0F79B.8090402 at cisco.com>
X-Mailer: Apple Mail (2.929.2)
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com

X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: sip at ietf.org

Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-02
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-Type: multipart/mixed; boundary="===============0144006264=="
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org


Either it's MIME or it's not.

By the time we work this out, SDP-NG might be real :-)

On Sep 29, 2008, at 11:43 AM, Paul Kyzivat wrote:


I agree it would be straightforward to define a rule that says one  
must recursively unwrap all multipart/mixed bodies in order to find  
other parts to process. But we ought to think if we really want to  
do that.



Potentially this could introduce a lot of extra processing. Its  
especially a problem if there are middle boxes that want to process  
SDP. They don't know if a given message contains SDP at all. And  
they perhaps don't want to process anything *except* SDP. But they  
will be forced to recursively open all the mixed parts to determine  
if there is an sdp for them.



(Or maybe this is a good thing because it will discourage middage middle  
boxes from looking at sdp.)


	Thanks,
	Paul

Dale.Worley at comcast.net wrote:

  From: Paul Kyzivat <pkyzivat at cisco.com>
  > But thinking about this, I suspect we define no semantics
  > anywhere (please correct me if I am wrong) about what nesting
  > means. Does a nested body require different interpretation to a
  > multipart body, and if so, how do I discover what that difference
  > is. All the nesting would seem to tell me is that there might be
  > a different relationship, but it does not tell me what that
  > relationship is.

  I agree that the current loose wording leaves something to be  
desired.

  I just don't know how to fix it.

ISTM that the solution to the problem of nesting is to enunciate a  
set

of recursive rules for processing an arbitary tree of nested body
parts.
The advantage of recursive rules is that stating rules recursively

acutally reduces the number of interpretations that seem reasonably  
at

first glance -- it helps one identify plausible solutions faster.  If
one looks at specific situations, it's very easy to state rules that
can't be properly generalized -- and such rules usually lead to
trouble (or at least, non-extensibility) later.
  Let me give a concrete example:
  Is an INVITE valid if it contains a body of:
	   multipart/mixed {
	      multipart/mixed {
		 multipart/mixed {
		    application/sdp
	   }}}
  Must the UAS keep unwrapping multiparts, looking for its SDP?
It seems that a multipart/mixed means "unwrap and process these body

parts".  Hence, the UAS must continue until it gets to the "leaf"  
body

parts.
If you think about it, there does not appear to be any other
processing rule that makes sense.
  And while we are discussing weird cases, what about:
	   multipart/mixed {
	      multipart/mixed {
		 multipart/mixed {
		    application/sdp-1
		 }
		 application/sdp-2
	   }}

  If the latter is legal at all, which sdp is the offer? And what  
should    happen to the other one?

This is, pretty much, equivalent to:
	   multipart/mixed {
	      application/sdp-1
             application/sdp-2
	   }
So the question is "If the sender provides us with two SDP bodies,
what should we do?"
Given that we envision a multipart/mixed might contain two

descriptions of the session in two different languages (with  
different

MIME types), it seems that a UA could either:
- pick one SDP and ignore the other, or

- reject the body as invalid (because two descriptions have the  
same type)

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

_______________________________________________
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



Attachment:
smime.p7s

Description: S/MIME cryptographic signature


Attachment:
smime.p7s

Description: S/MIME cryptographic signature


_______________________________________________
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