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
- [Sip] New I-D - TOTE - "INFO" on the media path Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Dean Willis
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Christer Holmberg
- [Sip] TOTE - "INFO" on the media path: Comment on… Christer Holmberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Jonathan Rosenberg
- Re: [Sip] TOTE - "INFO" on the media path: Commen… Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Ted Hardie
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Dean Willis
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Ted Hardie
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Dean Willis
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Dale.Worley
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Chris Boulton
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Hadriel Kaplan
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Hannes Tschofenig
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Hadriel Kaplan
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Chris Boulton
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Hadriel Kaplan
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Ted Hardie
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Ted Hardie
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Jonathan Rosenberg
- Re: [Sip] New I-D - TOTE - "INFO" on the media pa… Even, Roni