Re: [Sip] New I-D - TOTE - "INFO" on the media path
Ted Hardie <hardie@qualcomm.com> Mon, 25 February 2008 17:36 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 1F2243A6DCC; Mon, 25 Feb 2008 09:36:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.093
X-Spam-Level:
X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=-0.656, 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 s1bQdI6FhKGz; Mon, 25 Feb 2008 09:36:55 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2A63A6E1E; Mon, 25 Feb 2008 09:34:51 -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 BED463A6E18 for <sip@core3.amsl.com>; Mon, 25 Feb 2008 09:34:50 -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 RtdaMzDtfkXB for <sip@core3.amsl.com>; Mon, 25 Feb 2008 09:34:49 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D5CE43A6D32 for <sip@ietf.org>; Mon, 25 Feb 2008 09:33:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1203960815; x=1235496815; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=Mime-Version:=201.0|Message-Id:=20<p06240602c3e8a7d6c257 @[129.46.226.27]>|In-Reply-To:=20<47BF623C.8020105@cisco. com>|References:=20<47B6345B.4030807@cisco.com>=0D=0A=20< p06240601c3e0e71e3fef@[129.46.226.27]>=0D=0A=20<8F90CB13- F83A-4D95-82E4-63794937E8A9@softarmor.com>=0D=0A=20<p0624 0602c3e173da4d57@[24.4.239.115]>=0D=0A=20<AC12F0BB-E1BA-4 21A-B540-82DBC0CA2752@softarmor.com>=0D=0A=20<20080220214 4.m1KLi5WJ024161@dragon.ariadne.com>=0D=0A=20<47BF623C.80 20105@cisco.com>|Date:=20Mon,=2025=20Feb=202008=2009:33:3 3=20-0800|To:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com >,=0D=0A=20=20=20=20=20=20=20=20"Dale.Worley@comcast.net" =20<Dale.Worley@comcast.net>|From:=20Ted=20Hardie=20<hard ie@qualcomm.com>|Subject:=20Re:=20[Sip]=20New=20I-D=20- =20TOTE=20-=20"INFO"=20on=20the=20media=20path|Cc:=20"sip @ietf.org"=20<sip@ietf.org>|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5200,2160,5237"=3B=20a=3D"796277"; bh=uNuu7wmP7B67AQIMEHKkhxBpONr37cGtwzZAOlHS8Sc=; b=uUoe9iyGMiha9hQ2wzhhP53j64F48Lr34/x1vDSyEajywr1xntWgAwTo bmuC0e4llDZESRcspUByDKFF/OfXtQKPl838LthM2qYKgbNGhwg3xiakw Neb06si5oJd/lRYgDatdAr00H8XwGheLV49sU4WKAzSKoILl4hkIjeJb0 c=;
X-IronPort-AV: E=McAfee;i="5200,2160,5237"; a="796277"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2008 09:33:34 -0800
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1PHXZ17005720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2008 09:33:35 -0800
Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1PHXYhf004406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2008 09:33:34 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06240602c3e8a7d6c257@[129.46.226.27]>
In-Reply-To: <47BF623C.8020105@cisco.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>
Date: Mon, 25 Feb 2008 09:33:33 -0800
To: Jonathan Rosenberg <jdrosen@cisco.com>, "Dale.Worley@comcast.net" <Dale.Worley@comcast.net>
From: Ted Hardie <hardie@qualcomm.com>
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
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). 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. 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. The muxing seems liable to head of line blocking unless BEEP-like channels are introduced. 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? regards, Ted At 4:01 PM -0800 2/22/08, Jonathan Rosenberg wrote: >It only gets pushed to the client if the client indicates support for >it. Thus, the typical flow is: > >A->B : "hey, you can send me pic if you want" >B->A : "ok I will" > >and I think this is very much like: > >A->B : "please send be pic" >B->A : "ok I will" > >which is what SIP events is about. In terms of the need to understand >the semantics of the data, they are identical. >Now, the intended model in TOTE is that there would be two types of >purpose parameters. Global ones which are standardized, and a vendor >tree. The global ones require a specification, though it doesnt at the >moment require standards track. But it does need an RFC. I am happy to >debate standards track vs. ietf action. > >That said, depending on the purpose, I don't think there is that much >needed in such a spec. For example, for pic, something along the lines >of "this purpose is meant for picture sharing between users. For >example, in cases where a user with a cell phone snaps a picture during >a call and wishes to send it to the other person, or wishes to send an >existing file on disk. The received picture is normally rendered, >possibly with user permission, and possibly saved by the recipient. All >implementations MUST support image/jpg." >I'm not sure that much more is required; we could debate whether >max-size needs to be dealt with, and that could be done any number of >ways. The TOTE model would argue that you would do this by having a >message from recipient to sender, over this TOTE connection, with the >max size. Indeed, you could also have a message from sender to recipient >first that indicates an interest in sending a picture right now, >including picture metadata. This would imply that "pic" is really a >three way handshake, two of which are some new messages we'd need to >define (and presumably would be defined by the tote usage). We could >alternatively send those params through SDP, but that constrains us to >the O/A 2-way handshake; and as we have seen with things like SRTP, >having the flexibility of building the protocol without the constraints >of O/A is highly beneficial. It also means you can add new stuff without >extending SIP itself. > >What TOTE does is it avoids the need for this particular application to >define how to get connections set up through sip, how to secure them, >how to do nat traversal for them, how to signal what they are used for, >how to negotiate them, and so on. It also gives us the ability to share >connections across applications when it makes sense; this also allows us >to have very rich multi-app communications in one session without this >large number of connections. > >And so in my mind, it lowers the bar for new applications by providing a >framework for adding new ones without needing to change SIP, and to have >the flexibility of engineering the application ideally for its >particular needs. > >-Jonathan R. > >Dale.Worley@comcast.net wrote: >> From: Dean Willis <dean.willis@softarmor.com> >> >> Ok, I think I agree with you here. Each "purpose" would need to be >> very clearly specified, at roughly the same level of detail as is >> required for an event package or would be required for an INFO package >> if we were to go that way. >> >> IMHO the purposes need to be specified in *more* detail than an event >> package. The reason is that an event package is "pull" information, >> the meaning of the information is defined by the event-name, but the >> requestor is presumed to know *why* it wants the information, that is, >> what it intends to do based on that information. A TOTE object, like >> an INFO, is "push" information, and the attached meta-data must >> specify not only what the information means, but how the recipient is >> expected to act on it. >> >> Dale >> _______________________________________________ >> 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 >> > >-- >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 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