Re: [Sip] New I-D - TOTE - "INFO" on the media path
Ted Hardie <hardie@qualcomm.com> Tue, 19 February 2008 22:29 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 D1EF23A6CC3; Tue, 19 Feb 2008 14:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_17=0.6, 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 S0iPp5dQaLNW; Tue, 19 Feb 2008 14:29:50 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC6F3A6ABC; Tue, 19 Feb 2008 14:29:50 -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 937EB3A6876 for <sip@core3.amsl.com>; Tue, 19 Feb 2008 14:29:49 -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 wTfvEfudk5s7 for <sip@core3.amsl.com>; Tue, 19 Feb 2008 14:29:47 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E6AC73A6AD9 for <sip@ietf.org>; Tue, 19 Feb 2008 14:29:46 -0800 (PST)
X-IronPort-AV: E=McAfee;i="5200,2160,5233"; a="800002"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2008 14:29:44 -0800
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1JMThP8009220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Feb 2008 14:29:43 -0800
Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1JMTgJE021035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2008 14:29:43 -0800
Mime-Version: 1.0
Message-Id: <p06240601c3e0e71e3fef@[129.46.226.27]>
In-Reply-To: <47B6345B.4030807@cisco.com>
References: <47B6345B.4030807@cisco.com>
Date: Tue, 19 Feb 2008 14:29:41 -0800
To: Jonathan Rosenberg <jdrosen@cisco.com>, IETF SIP List <sip@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
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
Howdy, So I read this, then re-read this after having some more coffee, and I seriously considered re-reading it again after something alcoholic, just so I could see whether it seemed like a good idea in any of those states. Since my workplace declines to provide a wet bar, I didn't manage the last, so there is some chance I'm way off base here. First, some comments on the mechanics. Having a "purpose" that is not tied to the top level type of the mime type you're transporting opens you up to a lot of silly states. If I send you a purpose claiming something is a pic, but provide text/plain, is it ascii art? If I claim it is a pic, but provide application/octet-stream, will the data get fed to a renderer? That is, does the MIME type or the purpose handle disposition? The "Semantics" session seems to indicate it is purpose that governs this: Semantics: Each purpose MUST clearly define what its used for. T he definition must be sufficiently clear to allow an implementation to decide whether to render the object, what kind of UI to apply, how and where to store the object, how to process it, and so on. That's going to break how a lot of other things handle MIME object transport, and incidentally call into question a very basic mechanism for minting new application protocols currently in favor (that is, using specialty MIME types to trigger the handling). I'm not saying it's not a valid design choice, but it does run counter to the current set of trends. I also am concerned that in using the purpose, the design opens things up to crafted payload attacks. Second, none of the examples seem to show parameters being included with the MIME types; dealing with those provides a serious set of problems for interoperability (think of the charset parameters for an easy example). Supported MIME types may not be enough to determine whether you and your intended recipient actually do share enough for an interoperable transfer. This is also true with bucket MIME types (like message/cpim) which can contain other MIME types. I found your description of the session model and the answerer behavior somewhat unclear, and I'd like some additional clarification. In the answerer section, you say: An agent receiving an offer with an m=message line including the protocol "TOTE" or "TOTES" is being offered the opportunity to set up a TOTE session for one or more purposes. If the agent is capable of receiving objects using at least one of the purpose tokens associated with the tote session, the agent SHOULD accept the session. If it can receive none of them, it MUST reject the session (by setting the port to zero). The TOTE session described here looks like it is multiplexed for all the original purposes. For a receiver to remove one or more purposes from the original set, do I understand correctly that it needs to tear down the TOTE session and set up another? (On a side note, the TOTE vs. TOTES issue looks to have exactly the same ratholes we've seen before). Your draft says: An actual TOTE message can span several RFC4571 frames; this is analagous in general to reads off of a TCP connection - the amount of data read at a time has no bearing on the length of the actual message. As a consequence of this, even though RFC4571 has a limit of 64k, there is no constraint on the length of a TOTE message. I assume that this means that a TOTE implementation should not try to split its messages using any existing MIME facilities for that. Why not re-use the mechanism of things like message/partial? It would also be good to describe whether a MIME type like multipart/alternative SHOULD be split and each alternative listed in the SDP offer, or whether the multipart/alternative should be listed. If the former, the semantics of how to restore the default choice semantics of multipart/alternative should be described. If the latter, how does the receiver know anything about the interal parts' mime types? In other issues, I found the IANA consideration section very underspecified. This seriously needs to indicate when a purpose like "whiteboard" is general and when it is specific to an application. Having something that indicates what potential MIME types would be for this (and a way of updating the registration) would be much better than the "Description" field you have, and having both would be better still. The IANA considerations section also needs to re-mention the possibility of vendor specific purposes, and indicate whether they should conform to things like the SHOULD limit of 20 characters. (To put this another way, your IANA considerations only handle one of the two namespaces, and should mention the other and describe it as well). You have several examples (name, pic, bizcard, whiteboard) in the draft, but you do not register them. Why not? The Security Considerations don't begin to describe the issues here, and I assume that would change if this progressed. I look forward to hearing how the deep-packet inspection industry enjoys a bi-directional TLS-protected generic MIME tranport that gets through NATs and Firewalls using relays everyone thought they were deploying for VoIP. On the big picture, I think this is in the muddy middle in too many ways. Having an application linked to a specific transport is pretty well understood. Having a transfer protocol linked to very limited application semantics (e.g. FTP) is also pretty well understood. Having a generic rendezvous mechanism that multiplexes MIME objects intended for consumption by multiple different applications seems to run across some pretty rathole-infested ground (head of line blocking for my camera-control object when I'm sending media to a different application; MIME disposition ambiguity; interoperability problems when every vendor chooses their own specific purpose strings). If this is the cure, the disease was much, much worse than I thought. I look forward to my post-work re-read, Ted _______________________________________________ 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