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