Re: [Sip] New I-D - TOTE - "INFO" on the media path

Jonathan Rosenberg <jdrosen@cisco.com> Mon, 25 February 2008 18:42 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402AD28C336; Mon, 25 Feb 2008 10:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level:
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 Nbm5ueBBvWk1; Mon, 25 Feb 2008 10:42:06 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C812A28C24F; Mon, 25 Feb 2008 10:39:32 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753463A6D14 for <sip@core3.amsl.com>; Mon, 25 Feb 2008 10:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 KmPTP0q3G0nJ for <sip@core3.amsl.com>; Mon, 25 Feb 2008 10:39:30 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CEABE28C743 for <sip@ietf.org>; Mon, 25 Feb 2008 10:37:11 -0800 (PST)
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2008 13:37:05 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1PIb5ss014119; Mon, 25 Feb 2008 13:37:05 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1PIacVA007255; Mon, 25 Feb 2008 18:37:05 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 13:37:02 -0500
Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 13:37:02 -0500
Message-ID: <47C30AC3.4090407@cisco.com>
Date: Mon, 25 Feb 2008 13:36:51 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
References: <47B6345B.4030807@cisco.com> <p06240601c3e0e71e3fef@[129.46.226.27]> <8F90CB13-F83A-4D95-82E4-63794937E8A9@softarmor.com> <p06240602c3e173da4d57@[24.4.239.115]> <AC12F0BB-E1BA-421A-B540-82DBC0CA2752@softarmor.com> <200802202144.m1KLi5WJ024161@dragon.ariadne.com> <47BF623C.8020105@cisco.com> <p06240602c3e8a7d6c257@[129.46.226.27]>
In-Reply-To: <p06240602c3e8a7d6c257@[129.46.226.27]>
X-OriginalArrivalTime: 25 Feb 2008 18:37:02.0615 (UTC) FILETIME=[69C67270:01C877DD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3573; t=1203964626; x=1204828626; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:=20Re=3A=20[Sip]=20New=20I-D=20-=20TOTE=20-=20=22I NFO=22=20on=20the=20media=20path |Sender:=20 |To:=20Ted=20Hardie=20<hardie@qualcomm.com>; bh=BbVoUYuX/MKrLcj7wtqcWECho+7ujO3yqJVyiLFoXj0=; b=lDj7nYTENd6dRicPiw9hszt8cy3C1W2BLX9scP0FfvvisrCPzutF4etkM3 pdU05J1v2x+tlyu1foBUJ864352BW86XCkqgbuyyg6ZKBGQEHZJNKnihzp3z bQWSXc0120;
Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: "sip@ietf.org" <sip@ietf.org>
Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Ted,

I did see your note. Dean had responded, and your response to him, I 
thought, indicated that you were satisfied that having purposes 
specified (which was the intent of the draft) addressed your concerns. 
Sorry for having misunderstood. Some responses below:

Ted Hardie wrote:
> Jonathan,
> 	Did you see my messages in this thread?  I raised several
> issues with the approach you appear to be outlining again here, and I'm
> wondering if you saw them.  To recapitulate just slightly:
> 
> The negotiation model appears inadequate to deal with MIME types
> with significant parameters, with multipart MIME types, or with
> MIME types that have "bucket" semantics (like message/cpim, the
> container video types, or the 3ggp bucket mime types). 

OK; this was just a -00. There are two ways to deal with that:

1. add the additional negotiation needed for this as new SDP parameters, or

2. don't bother at all with MIME negotiation as part of SDP for TOTE; 
rather, each purpose would have a protocol to doing the negotiations 
needed to make its functionality work. This avoids needing to do a 
general purpose MIME thing. FOr example, in the case of "pic", we'd 
actually define a little protocol that negotiates pictures sizes and 
supported types. In that applications, buckets and multiparts aren't an 
issue.

I'm inclined towards #2 actually. But note that, I put into TOTE exactly 
the same level of MIME negotiation that SIP itself provides. SO if it is 
grossly inadequate here, so it is there.

> 
> Having a dispatch based on purpose without detailed specifications or
> reference to specific applications seems to hit a middle ground that's
> kind of nobody's sweet spot. 

That was never the intent. The IANA considerations section states that 
these require specification.

> A specific application already has detailed
> semantics that go beyond this purpose to actual decisions of whether
> to render or store, user permissions needed, sizes accepted, etc;
> generalized MIME transfer protocols like SMTP or HTTP already
> use a different system for deciding which applications to invoke
> when faced with a MIME object, and this forces systems with that
> logic to have a parallel track.

That would seem to argue for pulling the MIME aspects out of TOTE.

> 
> The muxing seems liable to head of line blocking unless BEEP-like
> channels are introduced.

This is discussed; if the purpose requires significant content, set it 
up as a separate session/tcp connection.

> 
> This seems to re-purpose the deployed TURN servers in ways that
> transform them into a generic NAT/Firewall avoidance mechanism
> for any MIME type.  You're listing that as a feature.  Isn't there
> a risk that security folks will see it as a bug?

I think you are getting wrapped up in the MIME parts of this, which is 
not the main point. The main point is that there are lots of cases where 
we need UA to UA communications - see:

http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-00.txt

I was trying to provide a common mechanism for addressing those cases 
where we don't want to send all this garbage over SIP - we want it over 
the media plane. Are you objecting to that?

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip