From simple-bounces@ietf.org Mon Feb 2 07:45:03 2009 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE4C28C15D; Mon, 2 Feb 2009 07:45:03 -0800 (PST) X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4875A3A689F; Mon, 2 Feb 2009 07:45:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090202154501.4875A3A689F@core3.amsl.com> Date: Mon, 2 Feb 2009 07:45:01 -0800 (PST) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-acm-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Alternative Connection Model for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-acm-00.txt Pages : 9 Date : 2009-01-30 This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976 in the following ways: it uses COMEDIA for TCP connection establishment, and it allows the usage of SDP in a more conventional way for conveying endpoint address information. Because of this, the model also allows for the usage of generic mainstream mechanisms for NAT traversal, instead of using MSRP relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-msrp-acm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-02074037.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Feb 3 02:23:13 2009 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BDD3A6AA0; Tue, 3 Feb 2009 02:23:13 -0800 (PST) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BAEB3A6AA6 for ; Tue, 3 Feb 2009 02:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_05=-1.11] 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 YqzrKP2LW6Zf for ; Tue, 3 Feb 2009 02:23:10 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id 199663A6A77 for ; Tue, 3 Feb 2009 02:23:09 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so929649tib.25 for ; Tue, 03 Feb 2009 02:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=MH4uFHxohUV0BpuWu6hIogRTTzbJ1o79tpO5rnGvOXc=; b=jvbe64dFP7AvdoIO14ojF5bigI9jQQVH43dFh4zJ5N2jXpEou8fyUEYWrcwGf3rLB8 VZMpPiq3hzkPQNAh4M3FIfrqfYx3hkoFSHjEFgM3gAGxRkR8BVV0FsRF7Ovl25YHTxEn szXscez6hqSSQwqCtcmxZEwKhKGS8o3NmqrdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=p1Naj8T73lO8hRRfjdxQIgpviHIrGxvsxkQZB5Y6nZneMMC4VQeMGWA4QdIDkeMmLc j1GriOJbKPoE9Dm1Jlu+fO35aEwq2S9/Jp25ctVfWLU9zzUKBr4GtMRSTzjwT+XIeHpp 4eSaIih/G8nvtcDdgWiavyMtGdidk5hYvbopc= MIME-Version: 1.0 Received: by 10.110.43.18 with SMTP id q18mr117370tiq.18.1233656569354; Tue, 03 Feb 2009 02:22:49 -0800 (PST) Date: Tue, 3 Feb 2009 15:52:49 +0530 Message-ID: From: Pankaj Munjal To: simple Subject: [Simple] Complete PIDF Schema (with extensions) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello all, Can someone kindly direct me to the link from where i can download the complete pidf schema? I'm looking for a pidf schema that also refers/includes the related pidf extensions, like data-model, geopriv, cipid namespaces. The available xsd's on net provide only the basic pidf schema with only tuple element. Any pointer shall be really helpful. Thanks in advance. Regards, Pankaj _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From fluffy@cisco.com Tue Feb 10 13:40:55 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141783A6A70; Tue, 10 Feb 2009 13:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 qizA9VZpycIA; Tue, 10 Feb 2009 13:40:54 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1F24E3A6D63; Tue, 10 Feb 2009 13:40:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,188,1233532800"; d="scan'208";a="134420633" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2009 21:40:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1ALevo5009324; Tue, 10 Feb 2009 13:40:57 -0800 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1ALeubu028488; Tue, 10 Feb 2009 21:40:57 GMT Message-Id: From: Cullen Jennings To: XMPP Working Group Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 14:40:56 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=982; t=1234302057; x=1235166057; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20FYI=3A=20XMPP=20BOF=20at=20IETF=2074 |Sender:=20; bh=Y6Bspjo5bhLdnoT2KZ+B8PZIiQHwGTAh9H/MvVzP7lo=; b=Pk90KOEFbCb6rP11z0wxSOqG7N/NpMfMcQ7XDA7gEYMwyZJq0214rgiwJH 9SF/iuYBxcQ9nXo3/nD9VWmBjZGdsOhxvRHsP/tODI1aZzBjDcC686xvcDNM YQLiArDtga; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sipping , rai@ietf.org, simple@ietf.org Subject: [Simple] FYI: XMPP BOF at IETF 74 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:40:55 -0000 There is going to be an XMPP BOF at ietf 74. The discussion is happening on the xmppwg@xmpp.org mailing list. List info at http://mail.jabber.org/mailman/listinfo/xmppwg The proposal is to form a RAI WG to do things such as: 1). Base spec revision - recent changes and how IETF can help improve the document 2). XMPP interop report (draft-saintandre-xmpp-feature-set) 3). Mapping between XMPP and SIMPLE (draft-saintandre-sip-xmpp-core- * drafts) 4). Mobile XMPP optimizations 5). IDNA and stringprep in RFC 3920 vs. IDNAbis and improved Unicode handling or "profiling" in rfc3920bis 6). BOSH 7). XMPP server MIB 8). "Client Certificate Management for SASL EXTERNAL" (XEP-0257) and other certificate related stuff (e.g. XEP-0250) 9). end-to-end encryption 10). Security labels in XMPP If you reply to this thread, please drop the rai, simple, and sipping groups and move the conversation to the to the xmppwg mailing list. Thanks, Cullen From HKaplan@acmepacket.com Sun Feb 15 09:39:59 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2163A68C6 for ; Sun, 15 Feb 2009 09:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] 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 b1lBLTGfamHb for ; Sun, 15 Feb 2009 09:39:58 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 358AD3A6813 for ; Sun, 15 Feb 2009 09:39:58 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 15 Feb 2009 12:38:46 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 15 Feb 2009 12:38:46 -0500 From: Hadriel Kaplan To: "simple@ietf.org" Date: Sun, 15 Feb 2009 12:38:45 -0500 Thread-Topic: draft-ietf-simple-msrp-acm-00 Thread-Index: AcmCymAUZBcDwjvrRuKe2cU6gt9B5gNLZFYw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Simple] draft-ietf-simple-msrp-acm-00 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 17:39:59 -0000 Sweet. Can we start a WGLC countdown for this draft? :) There are people waiting for this, there is running code, and I don't think= there were any outstanding issues from the last meeting around it. (though= I can barely remember the last meeting) -hadriel ________________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Friday, January 30, 2009 6:03 AM To: simple@ietf.org Subject: [Simple] draft-ietf-simple-msrp-acm-00 Hi, I've submitted the first draft-ietf-simple version of the msrp-acm draft. It is more or less identical to the previous version of the individual draf= t. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draf= t-ietf-simple-msrp-acm-00.txt Regards, Christer From adam@nostrum.com Tue Feb 17 14:34:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D723A69ED for ; Tue, 17 Feb 2009 14:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 JjbcF2xpktSI for ; Tue, 17 Feb 2009 14:34:06 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5BFA43A6812 for ; Tue, 17 Feb 2009 14:34:06 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n1HMYFnX005518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 16:34:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <499B3B67.6000006@nostrum.com> Date: Tue, 17 Feb 2009 16:34:15 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8998/Mon Feb 16 21:40:00 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: draft-ietf-simple-intradomain-federation@tools.ietf.org Subject: [Simple] Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:34:07 -0000 I have been asked to do a dedicated review of draft-ietf-simple-intradomain-federation, and have a number of comments. In general: much of the explanatory text is based on some of the growing pains associated with a relatively new technology. For example: In an ideal world, clients would all implement to standards and this would not happen, but in practice, the vast majority of presence and IM endpoints work only (or only work well) with the server from the same vendor. While this is true for the time being, I would hope that these impedance mismatches fade over time as people implement increasingly standard functionality (in fact, section 7.1.3 relies on this fact). Keep in mind that RFCs are permanent, while this problem is (hopefully) temporary. Section 5.2.2: The scaling problems mentioned here assume a very naïve design. Any product that performs this kind of task will cluster the routing proxy. Because the data used to process transactions is slow-changing hard state, such clusters can scale effectively infinitely. Section 5.2.3: it would be useful to detail some potential protocols for the client/database interaction. Making "Database" a SIP redirect server, for example, would allow this scenario to work with a broad base of deployed clients. Section 5.2.4: it would be helpful to cite the p2psip work as a candidate for doing this in the future. Section 5.2.5: the caveat about the number of servers should probably be stronger here; this approach completely defeats any scaling-related partitioning. Section 6.1.1: if the percentage of the community that is offline at any given time is large, this approach simply moves any subscription scaling problem up to the subscriptions on the database. While not a show-stopper, this is an important property of the system that should be explained. It should also be noted that static assignment to a partitioned database can be used to solve this problem (i.e., you're using the approaches from section 5, but at the database level instead of the presence/IM server level). Section 6.1.2: this has the same scaling issues as 6.1.1. Section 6.1.5: This should go into more detail about what happens when multiple servers think they're authoritative for a user -- e.g., the forked SUBSCRIBE will establish multiple subscriptions, and the forking server will be forced to form a coherent (if not necessarily complete) state for the subscribing user... Section 6.2: this should also talk about storing policy on an external server using, e.g., presence rules and XCAP. That way, each presence server can access the same policy information. Section 7.1.1: in the third bullet, why is the request routed to the parent instead of to the root? Routing to the root would achieve the same effect, but with less traffic. Section 7.1.2.2: The advice on presence subscription rejection is precisely opposite from the common policy model, in which rights are absent unless granted; and, once granted by a rule, cannot be revoked. The interaction between these two diametrically opposed models is likely to lead to some unwanted surprises. I think the common policy approach is the correct one to take here. Consider, for example, the case in which I instruct an off-the-shelf geoloc server to allow Robert to subscribe to my location information, but no one else. It interprets this to mean "reject subscriptions from everyone but Robert" (which is a reasonable implementation choice). Now, this server is used as a leaf in a hierarchical tree of presence servers. Suddenly, no one can see *any* of my presence information except for Robert! That's certainly not what I intended. It seems quite reasonable for a subscription rejection at a node other than the root simply be interpreted to mean "the presence information from this branch of the tree shall not be composed into the document, but other information is still allowed." Section 7.1.2.3: Figure 11 (and the accompanying text) implies a push model. This can, of course, be achieved through a pull model as well, such as XCAP. Such an approach requires more integrated client support, but eliminates the need for a portal (with the trade-off being deployment of an XCAP server). Section 7.2: The formula given to demonstrate commutativity is a bit confusing. I think you actually mean something like: Pi(Pj(x1..xm),y1..yn) = Pj(Pi(y1..yn),x1..xm) for all possible inputs x1..xm and y1..yn. Section 7.2.1: This entire scheme seems less well baked than the rest of the document. For example, I could point to concrete standardized mechanisms to create all the systems described so far; but for 7.2.1, I'd have to do some non-standard stuff (e.g., indication of a loop in a back-end subscription). /a From dehne@colibria.com Wed Feb 18 06:09:27 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7B03A6D35 for ; Wed, 18 Feb 2009 06:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 QTzMucl-3EJs for ; Wed, 18 Feb 2009 06:09:27 -0800 (PST) Received: from mail.colibria.com (pc2.colibria.com [194.143.13.66]) by core3.amsl.com (Postfix) with ESMTP id 329FD3A69A0 for ; Wed, 18 Feb 2009 06:09:25 -0800 (PST) Received: from [192.168.1.183] (unknown [192.168.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.colibria.com (Postfix) with ESMTP id E663F57918; Wed, 18 Feb 2009 15:09:33 +0100 (CET) Message-ID: <499C169D.6070005@colibria.com> Date: Wed, 18 Feb 2009 15:09:33 +0100 From: Sebastian Dehne User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ben Campbell References: <7E27141E2F9038419E1FA26127E67EC4B4E71D@rvil-mail1.RADVISION.com> <49534450.6040103@ag-projects.com> <7E27141E2F9038419E1FA26127E67EC4B4E8A3@rvil-mail1.RADVISION.com> <4958F64A.8020702@cisco.com> <431F8A31-54B9-4891-AD22-A1A528513674@estacado.net> In-Reply-To: <431F8A31-54B9-4891-AD22-A1A528513674@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] MSRP (RFC 4975) question X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:09:28 -0000 Hi, One more thing: If the sender is currently busy transmitting a large chunk and receives a 413 while during so, should A) the sender expect another response for it's chunk (request) once he has sent the tail-line and thus completed/interrupted this chunk? Or B) will the already received 413 response count as a closure for the 'transaction'? In case of B, the receiver must make sure to not send another response once it sees that an incoming chunk was ended in case it has already sent a response to it. In case of A, the receiver will always send a response as soon as it sees the end of a chunk, regardless if it had sent a 413 previously. Thanks Sebastian On 01/06/2009 11:16 PM, Ben Campbell wrote: > > > On Dec 29, 2008, at 10:09 AM, Paul Kyzivat wrote: > >> I'm quite sure the intent was that the response may be sent for the >> chunk in progress. >> >> Thanks, >> Paul >> > > Yes, that was definitely the intent. The "a chunk" in the quoted text > can certainly still be "the chunk". > >> Gilad Govrin wrote: >>> Hi, >>> First of all thanks for the response. >>> Actually I thought about this quote, but from this quote it is not clear >>> whether the 413 received for the current chunk that is in sending >>> process. >>> Since it says: "while in the process of sending a chunk" and not "while >>> in the process of sending the chunk". >>> The situation may be sending chunk x and than sending chunk y >>> (interruptible), then receive 413 for chunk x, in this case we must >>> interrupt chunk y. >>> Gilad >>> -----Original Message----- >>> From: Denis Bilenko [mailto:denis@ag-projects.com] Sent: Thursday, >>> December 25, 2008 10:29 AM >>> To: Gilad Govrin >>> Cc: simple@ietf.org >>> Subject: Re: [Simple] MSRP (RFC 4975) question >>> I think you don't have to wait for a complete chunk in order to send the >>> response. >>> Here's a quote from RFC that implies that: >>> If the sender receives the 413 while in the process of sending >>> a chunk, and the chunk is interruptible, the sender MUST interrupt it. >>> (http://tools.ietf.org/html/rfc4975#section-10.5) >>> Gilad Govrin wrote: >>>> Hi All, >>>> Sorry for asking again but I didn't get any response for this one, >>>> does anyone has insights about this one? >>>> I need clarifications for issues raised while implementing RFC 4975 >>> MSRP. >>>> In section 7.1.1 the RFC is "strongly recommended" to use >>>> interruptible mechanism, meaning to send chunks greater than 2048 and >>>> interrupt it when others are waiting to send their own messages on the >>>> same connection, and as a result split large messages into fewer >>>> chunks as possible. >>>> Based on this fact, Theoretically, senders that implemented >>>> interruptible mechanism can send 4GB file in one chunk (assuming no >>>> one interrupt it while sending). >>>> The receiver may detect that he don't want to process this message the >>>> moment he gets the headers for example unsupported content type. >>>> The question is whether the receiver is allow to send reject response >>>> while receiving chunk data, or he should wait for the end-line and >>>> only then send this response? >>>> Thanks in advance, >>>> Gilad >>>> >>>> >>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From rfc-editor@rfc-editor.org Wed Feb 18 11:42:51 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802113A693F; Wed, 18 Feb 2009 11:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.247 X-Spam-Level: X-Spam-Status: No, score=-16.247 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 9t4JG5EIN1yD; Wed, 18 Feb 2009 11:42:50 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 29B943A6767; Wed, 18 Feb 2009 11:42:50 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id D275F226FFE; Wed, 18 Feb 2009 11:42:39 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090218194239.D275F226FFE@bosco.isi.edu> Date: Wed, 18 Feb 2009 11:42:39 -0800 (PST) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 5438 on Instant Message Disposition Notification (IMDN) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:42:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5438 Title: Instant Message Disposition Notification (IMDN) Author: E. Burger, H. Khartabil Status: Standards Track Date: February 2009 Mailbox: eburger@standardstrack.com, hisham.khartabil@gmail.com Pages: 38 Characters: 83723 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-imdn-10.txt URL: http://www.rfc-editor.org/rfc/rfc5438.txt Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages. The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From ggb@tid.es Thu Feb 19 09:32:27 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2ED3A67F7 for ; Thu, 19 Feb 2009 09:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1Km5UUC87Dpx for ; Thu, 19 Feb 2009 09:32:26 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by core3.amsl.com (Postfix) with ESMTP id 871363A67FA for ; Thu, 19 Feb 2009 09:32:26 -0800 (PST) Received: from correo.tid.es (htcasmad1.hi.inet [10.95.67.73]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFB00MM6Q2ENJ@tid.hi.inet> for simple@ietf.org; Thu, 19 Feb 2009 18:32:38 +0100 (MET) Received: from [10.95.50.41] (10.95.67.43) by htcasmad1.hi.inet (10.95.67.73) with Microsoft SMTP Server id 8.1.340.0; Thu, 19 Feb 2009 18:32:38 +0100 Date: Thu, 19 Feb 2009 18:32:38 +0100 From: Gustavo Garcia To: simple@ietf.org Message-id: <499D97B6.2020208@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3 Cc: =?ISO-8859-1?Q?Jos=E9_Luis_Mart=EDn_Peinado?= Subject: [Simple] [Fwd: I-D Action:draft-garcia-simple-poke-01.txt] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 17:32:27 -0000 In this new version we have left just the simplest possible message format as proposed by most of the people in the WG. If there is interest in progressing this doc, in the next version we would change the name from "poke" to "attention" to be aligned with the XMPP equivalent message. Comments are welcome. BR. G. -------- Original Message -------- Subject: I-D Action:draft-garcia-simple-poke-01.txt Date: Thu, 12 Feb 2009 12:15:01 +0100 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Attention Request (POKE) for Instant Messaging Author(s) : G. Garcia, J. Martin Filename : draft-garcia-simple-poke-01.txt Pages : 7 Date : 2009-02-12 This document specifies a message content type and XML format to request attention from a targeted user. This feature is usually known as poke, nudge or buzz in existing messaging platforms. Its primary use is as an additional instant messaging capability that can be sent in the middle of a instant messaging session or in a standalone message at any time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-simple-poke-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From geir.sandbakken@tandberg.com Thu Feb 19 10:58:50 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19813A6B54 for ; Thu, 19 Feb 2009 10:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kbbv3gLbb+Vr for ; Thu, 19 Feb 2009 10:58:50 -0800 (PST) Received: from mail193.messagelabs.com (mail193.messagelabs.com [85.158.140.195]) by core3.amsl.com (Postfix) with SMTP id B42FD3A6954 for ; Thu, 19 Feb 2009 10:58:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-10.tower-193.messagelabs.com!1235069940!9990043!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 9577 invoked from network); 19 Feb 2009 18:59:00 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-10.tower-193.messagelabs.com with SMTP; 19 Feb 2009 18:59:00 -0000 Received: from ultra.rd.tandberg.com ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 19:59:01 +0100 Received: from [10.47.5.228] (GSandbakkenT61.rd.tandberg.com [10.47.5.228]) by ultra.rd.tandberg.com (8.13.1/8.13.1) with ESMTP id n1JIx0eb010559 for ; Thu, 19 Feb 2009 19:59:00 +0100 Message-ID: <499DABF5.4080304@tandberg.com> Date: Thu, 19 Feb 2009 19:59:01 +0100 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Simple Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2009 18:59:01.0109 (UTC) FILETIME=[205EAA50:01C992C4] Subject: [Simple] Call for Multi-party chat early reviewers X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:58:50 -0000 Experts, I plan to make another version of the multi-party chat draft available soon, and wonder if someone would like to review it before it is published? The hope is to get it as close as possible to a finished state - before the upcoming cut-off date. Thanks, Geir Arne From ben@estacado.net Fri Feb 20 12:36:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3856A3A6936 for ; Fri, 20 Feb 2009 12:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 BjF60pMpqipB for ; Fri, 20 Feb 2009 12:36:06 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 00DC83A6988 for ; Fri, 20 Feb 2009 12:36:05 -0800 (PST) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1KKaDwA044382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Feb 2009 14:36:14 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <59D6BFA4-FC4D-44D5-A85B-78F62FF14A88@estacado.net> From: Ben Campbell To: Simple WG , Christer Holmberg Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 14:36:13 -0600 X-Mailer: Apple Mail (2.930.3) Subject: [Simple] msrp-acm: Use Cases Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:36:07 -0000 Hi, I've been working through draft-ietf-simple-msrp-acm-00, and have a few new thoughts about it. I am breaking these up into separate emails, to try to avoid discussion thread confusion. I think the draft needs more analysis of the problems or use cases this draft sets out to solve. It may be this analysis exists in people's heads, but I think we should document it here. In the case of the COMEDIA usage, there are some obvious use cases (the OMA media server use case mentioned in the draft, as well as situations were the network topology prevents the answering party from accepting TCP connections, while the offering party might could. OTOH, the use cases for the c-line based addressing model are less clear to me. The draft states the use of more generic NAT traversal techniques as a motivation. We've done some internal white boarding, and I am not yet convinced this change is necessary for the use of TURN-TCP or ICE-TCP. In the case of TURN, an MSRP endpoint can simple construct it's session MSRP URL using the TURN allocation. ICE, on the other hand, defines it's own connection model. It seems like that if an MSRP endpoint wants to use ICE, it simply uses the ICE connection model rather than the base MSRP model, and things just work. (It gets more complicated if you want to use MSRP relays as ICE candidates--but my instinct tells me that is not a requirement.) For that matter, ICE- TCP has it's own mechanism for selecting the connection direction. Thanks! Ben. From ben@estacado.net Fri Feb 20 12:52:03 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4153A698E for ; Fri, 20 Feb 2009 12:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0S76H9Ciq4hh for ; Fri, 20 Feb 2009 12:52:03 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 800F33A689C for ; Fri, 20 Feb 2009 12:52:02 -0800 (PST) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1KKaDwC044382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Feb 2009 14:36:16 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Simple WG , Christer Holmberg Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 14:36:16 -0600 X-Mailer: Apple Mail (2.930.3) Subject: [Simple] msrp-acm: 2 Separate Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:52:04 -0000 Hi, I've been working through draft-ietf-simple-msrp-acm-00, and have a few new thoughts about it. I am breaking these up into separate emails, to try to avoid discussion thread confusion. I think we should be more clear on the separation between the COMEDIA and the C-Line connection model bits of this draft. My understanding is that they are completely orthagonal, is this correct? Or does one require the other? From a process perspective, I don't think the COMEDIA bits are controversial. I would even support those as MUST level updates to the base MSRP spec. OTOH, I think the C-line connection part needs further discussion and work. Thanks! Ben. From ben@estacado.net Fri Feb 20 12:52:05 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C253A6A60 for ; Fri, 20 Feb 2009 12:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 t3Ja-d8GNz2t for ; Fri, 20 Feb 2009 12:52:04 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id D14CF3A6988 for ; Fri, 20 Feb 2009 12:52:03 -0800 (PST) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1KKaDwB044382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Feb 2009 14:36:14 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> From: Ben Campbell To: Simple WG , Christer Holmberg Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 14:36:14 -0600 X-Mailer: Apple Mail (2.930.3) Subject: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:52:05 -0000 Hi, I've been working through draft-ietf-simple-msrp-acm-00, and have a few new thoughts about it. I am breaking these up into separate emails, to try to avoid discussion thread confusion. One of the motivations for the C-Line connection model in this draft is the use of SBCs/ALGs. I can accept that motivation, but I am troubled by the inability of an endpoint using this model to interoperate with a peer that needs to use an MSRP relay. The ability to fail back to standard MSRP behavior is not very satisfying, since I doubt network routing policy will _allow_ an endpoint to fall back to standard behavior when SBCs are involved. In my opinion, we should explore approaches where the SBC modifies the MSRP "path" attribute in the SDP, which I think can be made to work even when the peer uses one or more MSRP relays. I realize that this creates new work for SBCs-- but that might be worth it for a more interoperable solution. This would, however, force MSRP endpoints to change how they match inbound messages to a session. For example, it might look just at the session-id part of the MSRP URI, and ignore changes to the host/domain part. We would need to think about the security properties of such a change. Thanks! Ben. From ben@estacado.net Fri Feb 20 15:21:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8493A63EC for ; Fri, 20 Feb 2009 15:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 mOfzHLXMHJw4 for ; Fri, 20 Feb 2009 15:21:06 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 13CD33A6981 for ; Fri, 20 Feb 2009 15:21:05 -0800 (PST) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1KNLDnN011782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Feb 2009 17:21:14 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: jdrosen@cisco.com, avshalom@il.ibm.com, smythc@avaya.com, Francois Audet , Hisham Khartabil Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 17:21:13 -0600 X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: [Simple] Comments on draft-ietf-simple-intradomain-federation-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:21:07 -0000 Hi, Hisham asked me to review draft-ietf-simple-intradomain-federation-02: General: --I think this is a good analysis in general, but I found it easy to get lost in all the models. An early summary or terminology section might help readers get the whole picture, prior to diving into detail on each model. Maybe even a taxonomy diagram. (There are a lot of new terms in this draft, so a glossary would help one way or another.) -- It's not clear to me what this document sets out to accomplish. Will it become a framework for discussing standards work? An architecture document? Recommended best practices? Something else? --I am a little skeptical that the same set of models apply for both presence and messaging. Certainly some models work better for one than the other. I think it is likely to have overlaid models where presence and messaging are treated differently. I can also imagine buying a presence product from one vendor, and a messaging product from another. --This version appears to change the terminology from "federation" to "bridging" to avoid confusion with inter-domain federation. The term "federation" still shows up quite a bit, though. (In particular, in the file name.) Specifics: Section 1, third from last paragraph (definition of "domain") The draft defines domain in terms of "the right hand side of the @- sign". I think we are really talking about administrative domains, which may or may not line up with DNS domains. In fact, limiting domains to DNS domains has the effect of prejudicing us against the use of different DNS domains for the purposes of partitioning. There are well known limitations to that approach, but it should be evaluated based on those limitations. (I point to the fact that this draft goes on to discuss such approaches as evidence that "intra- domain" describes administrative domains rather than DNS domains.) (I find it mildly ironic this draft lists Avshalom with a sub-domained email address :-) ) -- Section 2, 2nd paragraph: "There is never database replication or state replication across federated systems" Never say never. Such replication may not be common, but it is certainly possible. -- ... 3rd paragraph: clustering always occurs amongst components from the same vendor" Never say "always", either :-) -- Section 3.4: I am skeptical of using "people don't follow standards" as a motivation for more standards. (assuming any standards work comes out of this, of course.) -- ... Last Paragraph, last sentence: s/specified/specific -- Section 5.2: I think the distinction between "central database" and "routing proxy" is artificial, at least at a logical level. The routing proxy approach is likely to have in practice multiple proxies looking at a central database. The central database approach simply moves the routing function into each PS--but the function still logically exists. -- Section 5.2.6: Any deployable version of this is probably the same as "central database" for all practical purposes. Or more to the point, two models that differ only in how the provisioning system works are probably the same model from a presence and IM perspective. -- Section 6: The term "exclusive" seems a bit off to me. The difference between the exclusive and partitioned model seems sort of apples and oranges. A cleaner taxonomy might distinguish between "static" and "dynamic" assignment of users to servers, and "single-server" vs "multiple- servers" at any point in time. Can't you have static multi-server, static single-server, dynamic single-server, and dynamic multi-server? -- Section 7, last paragraph: Since the example is really not intra-domain bridging, can we omit it? Or maybe have a separate section for things that might look like intra- domain bridging at first, but on inspection are not? -- Section 7.1.1, first sentence: All of these items may or may not be needed, depending on how the servers communicate (back-end subscriptions vs PUBLISH, etc.) I think we mean to say "and/or", or that "each server needs to be provisioned with some combination of...". -- 7.1.2, third paragraph: Any reason not to reference RFC4474 as well as 3325? -- 7.1.2.2, starting in paragraph 2: I think it's important to mention (again) that this approach to privacy assumes that back-end subscriptions always happen on behalf of the end watcher. Also, this model does not hold if servers send PUBLISH to each other, does it? (i.e. back-end subscriptions are recommended over PUBLISH?) Discussion of security differences between publish and sub/not models may be worthy of the security considerations section. Section 7.1.3, 2nd bullet: It seems like this statement is true in any multi-vendor network, isn't it? From christer.holmberg@ericsson.com Sat Feb 21 14:24:43 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB833A63EC for ; Sat, 21 Feb 2009 14:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Imc+fmha7lHR for ; Sat, 21 Feb 2009 14:24:42 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 481E53A677D for ; Sat, 21 Feb 2009 14:24:42 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EF8CA205B2; Sat, 21 Feb 2009 23:24:56 +0100 (CET) X-AuditID: c1b4fb3e-ab0b9bb000001315-2d-49a07f385adf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D17BC205AB; Sat, 21 Feb 2009 23:24:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Feb 2009 23:24:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Feb 2009 23:24:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: msrp-acm: 2 Separate Extensions thread-index: AcmTmuKp3gaowEbvRtym7FM1Fx2aNwAC/Fgg References: From: "Christer Holmberg" To: "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 21 Feb 2009 22:24:56.0845 (UTC) FILETIME=[39C9DBD0:01C99473] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] msrp-acm: 2 Separate Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:24:43 -0000 Hi Ben,=20 >I've been working through draft-ietf-simple-msrp-acm-00, and have a few new thoughts about it. I am breaking these up into separate emails, to try to avoid discussion thread confusion. > >I think we should be more clear on the separation between the COMEDIA and the C-Line connection model bits of this draft. My understanding is that they are completely orthagonal, is this correct? Or does=20 >one require the other? > >From a process perspective, I don't think the COMEDIA bits are controversial. I would even support those as MUST level updates to the base MSRP spec. OTOH, I think the C-line connection part needs=20 >further discussion and work. The c-line connection part is optional, and the COMEDIA part can be used without it. I have tried to indicate that in a few places in the draft, but if you think it needs to be further clarified I am happy to add/modify text. Regards, Christer From HKaplan@acmepacket.com Sun Feb 22 16:44:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57B13A6844 for ; Sun, 22 Feb 2009 16:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] 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 PmAi1IHu6axF for ; Sun, 22 Feb 2009 16:44:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DFE043A6783 for ; Sun, 22 Feb 2009 16:44:30 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 22 Feb 2009 19:43:25 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 22 Feb 2009 19:43:25 -0500 From: Hadriel Kaplan To: Ben Campbell , Simple WG , Christer Holmberg Date: Sun, 22 Feb 2009 19:43:03 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: AcmTnPzJsqj5OzIBQ4ejcHAstXvBdQBcAJ/g Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> In-Reply-To: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 00:44:32 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Friday, February 20, 2009 3:36 PM > > One of the motivations for the C-Line connection model in this draft > is the use of SBCs/ALGs. The real benefit of that is the SBCs/ALGs don't need to be upgraded at all.= For example, I can't speak for the other vendors, but we've tested the ms= rp-acm draft going back to some fairly old code of ours and it works, with = a one line config change if any. I am very sympathetic with Adam's concern= s that it's the tail wagging the dog, but if we're going to do a change any= way, it might as well follow normal SDP. > I can accept that motivation, but I am > troubled by the inability of an endpoint using this model to > interoperate with a peer that needs to use an MSRP relay. The ability > to fail back to standard MSRP behavior is not very satisfying, since I > doubt network routing policy will _allow_ an endpoint to fall back to > standard behavior when SBCs are involved. I agree. Odds are that if you're talking through an SBC-type provider, the= y won't support the "legacy" behavior. I do wonder how much "legacy" MSRP really exists, though. I know we all fo= cus on different customers and users, but I'm really having a hard time bel= ieving we need to worry much about RFC 4976. My company's test group had a= hard time even finding any rfc4975 endpoints to test against, and we only = found one rfc4976 Relay. We know the endpoint support is coming, which is = why we'd like to make this change now, asap. > In my opinion, we should > explore approaches where the SBC modifies the MSRP "path" attribute in > the SDP, which I think can be made to work even when the peer uses one > or more MSRP relays. I realize that this creates new work for SBCs-- > but that might be worth it for a more interoperable solution. > This would, however, force MSRP endpoints to change how they match > inbound messages to a session. For example, it might look just at the > session-id part of the MSRP URI, and ignore changes to the host/domain > part. We would need to think about the security properties of such a > change. I'm ok with that - but how could it work? The real issue has always been t= he matching of MSRP messages to the session, where the binding of the path = IP:port to the IP/TCP socket info was what killed it. No? I admit I don't= fully grok the rfc4976 Relay approach, but I thought it was fundamentally = incompatible with breaking that binding. -hadriel From ben@estacado.net Sun Feb 22 18:13:38 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2B43A69E3 for ; Sun, 22 Feb 2009 18:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] 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 qjGBjGmfcU4I for ; Sun, 22 Feb 2009 18:13:35 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id C47263A6952 for ; Sun, 22 Feb 2009 18:13:34 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1N2DeiS005447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Feb 2009 20:13:45 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 20:13:40 -0600 References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 02:13:38 -0000 On Feb 22, 2009, at 6:43 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Ben Campbell >> Sent: Friday, February 20, 2009 3:36 PM >> >> One of the motivations for the C-Line connection model in this draft >> is the use of SBCs/ALGs. > > The real benefit of that is the SBCs/ALGs don't need to be upgraded > at all. For example, I can't speak for the other vendors, but we've > tested the msrp-acm draft going back to some fairly old code of ours > and it works, with a one line config change if any. I am very > sympathetic with Adam's concerns that it's the tail wagging the dog, > but if we're going to do a change anyway, it might as well follow > normal SDP. I assume your old code already handles TCP based media? I certainly understand the desire to make this work with existing code. It's a question of whether making this interop with 4976 relays is worth the change (assuming my proposal actually works--it still needs more thought.) . At least it would be a smaller change than, say, implementing an MSRP relay in an SBC. > > > >> I can accept that motivation, but I am >> troubled by the inability of an endpoint using this model to >> interoperate with a peer that needs to use an MSRP relay. The ability >> to fail back to standard MSRP behavior is not very satisfying, >> since I >> doubt network routing policy will _allow_ an endpoint to fall back to >> standard behavior when SBCs are involved. > > I agree. Odds are that if you're talking through an SBC-type > provider, they won't support the "legacy" behavior. > > I do wonder how much "legacy" MSRP really exists, though. I know we > all focus on different customers and users, but I'm really having a > hard time believing we need to worry much about RFC 4976. My > company's test group had a hard time even finding any rfc4975 > endpoints to test against, and we only found one rfc4976 Relay. We > know the endpoint support is coming, which is why we'd like to make > this change now, asap. I seem to recall Robert mentioning some implementations at the last SIPit. I don't recall the details. Robert? > > > >> In my opinion, we should >> explore approaches where the SBC modifies the MSRP "path" attribute >> in >> the SDP, which I think can be made to work even when the peer uses >> one >> or more MSRP relays. I realize that this creates new work for SBCs-- >> but that might be worth it for a more interoperable solution. >> This would, however, force MSRP endpoints to change how they match >> inbound messages to a session. For example, it might look just at the >> session-id part of the MSRP URI, and ignore changes to the host/ >> domain >> part. We would need to think about the security properties of such a >> change. > > I'm ok with that - but how could it work? The real issue has always > been the matching of MSRP messages to the session, where the binding > of the path IP:port to the IP/TCP socket info was what killed it. > No? I admit I don't fully grok the rfc4976 Relay approach, but I > thought it was fundamentally incompatible with breaking that binding. You are correct, RFC 4975 currently says you match the entire MSRP URI to the session, which includes the address and port, or conceivably a host name and port. But if we updated that to only match on the Session ID (i.e. that part of the URL right of the "/", it _might_ be good enough. This would allow the session match to work even if the address:port gets changed in flight. We already say the session ID should be hard to guess. It seems to me that the security properties of a hard-to-guess session id is not very different than the same id concatenated with a fairly-easy-to- guess port and a pretty-much-public-knowledge address. But I would want input from our security experts to be sure. > > > -hadriel From dehne@colibria.com Mon Feb 23 04:48:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C873A69F5 for ; Mon, 23 Feb 2009 04:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NN7ef9sNKMRN for ; Mon, 23 Feb 2009 04:48:52 -0800 (PST) Received: from mail.colibria.com (pc2.colibria.com [194.143.13.66]) by core3.amsl.com (Postfix) with ESMTP id D84CD3A68AD for ; Mon, 23 Feb 2009 04:48:51 -0800 (PST) Received: from [192.168.1.183] (unknown [192.168.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.colibria.com (Postfix) with ESMTP id 4941B57654; Mon, 23 Feb 2009 13:49:05 +0100 (CET) Message-ID: <49A29B41.8010008@colibria.com> Date: Mon, 23 Feb 2009 13:49:05 +0100 From: Sebastian Dehne User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: simple@ietf.org References: <7E27141E2F9038419E1FA26127E67EC4B4E71D@rvil-mail1.RADVISION.com> <49534450.6040103@ag-projects.com> <7E27141E2F9038419E1FA26127E67EC4B4E8A3@rvil-mail1.RADVISION.com> <4958F64A.8020702@cisco.com> <431F8A31-54B9-4891-AD22-A1A528513674@estacado.net> <499C169D.6070005@colibria.com> In-Reply-To: <499C169D.6070005@colibria.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat Subject: Re: [Simple] MSRP (RFC 4975) question X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:48:53 -0000 Hi, Could anyone please comment on this? Thank you. kind regards, Sebastian On 02/18/2009 03:09 PM, Sebastian Dehne wrote: > Hi, > > One more thing: If the sender is currently busy transmitting a large > chunk and receives a 413 while during so, should A) the sender expect > another response for it's chunk (request) once he has sent the tail-line > and thus completed/interrupted this chunk? Or B) will the already > received 413 response count as a closure for the 'transaction'? > > In case of B, the receiver must make sure to not send another response > once it sees that an incoming chunk was ended in case it has already > sent a response to it. In case of A, the receiver will always send a > response as soon as it sees the end of a chunk, regardless if it had > sent a 413 previously. > > Thanks > Sebastian > > On 01/06/2009 11:16 PM, Ben Campbell wrote: >> >> >> On Dec 29, 2008, at 10:09 AM, Paul Kyzivat wrote: >> >>> I'm quite sure the intent was that the response may be sent for the >>> chunk in progress. >>> >>> Thanks, >>> Paul >>> >> >> Yes, that was definitely the intent. The "a chunk" in the quoted text >> can certainly still be "the chunk". >> >>> Gilad Govrin wrote: >>>> Hi, >>>> First of all thanks for the response. >>>> Actually I thought about this quote, but from this quote it is not >>>> clear >>>> whether the 413 received for the current chunk that is in sending >>>> process. >>>> Since it says: "while in the process of sending a chunk" and not "while >>>> in the process of sending the chunk". >>>> The situation may be sending chunk x and than sending chunk y >>>> (interruptible), then receive 413 for chunk x, in this case we must >>>> interrupt chunk y. >>>> Gilad >>>> -----Original Message----- >>>> From: Denis Bilenko [mailto:denis@ag-projects.com] Sent: Thursday, >>>> December 25, 2008 10:29 AM >>>> To: Gilad Govrin >>>> Cc: simple@ietf.org >>>> Subject: Re: [Simple] MSRP (RFC 4975) question >>>> I think you don't have to wait for a complete chunk in order to send >>>> the >>>> response. >>>> Here's a quote from RFC that implies that: >>>> If the sender receives the 413 while in the process of sending >>>> a chunk, and the chunk is interruptible, the sender MUST interrupt it. >>>> (http://tools.ietf.org/html/rfc4975#section-10.5) >>>> Gilad Govrin wrote: >>>>> Hi All, >>>>> Sorry for asking again but I didn't get any response for this one, >>>>> does anyone has insights about this one? >>>>> I need clarifications for issues raised while implementing RFC 4975 >>>> MSRP. >>>>> In section 7.1.1 the RFC is "strongly recommended" to use >>>>> interruptible mechanism, meaning to send chunks greater than 2048 and >>>>> interrupt it when others are waiting to send their own messages on the >>>>> same connection, and as a result split large messages into fewer >>>>> chunks as possible. >>>>> Based on this fact, Theoretically, senders that implemented >>>>> interruptible mechanism can send 4GB file in one chunk (assuming no >>>>> one interrupt it while sending). >>>>> The receiver may detect that he don't want to process this message the >>>>> moment he gets the headers for example unsupported content type. >>>>> The question is whether the receiver is allow to send reject response >>>>> while receiving chunk data, or he should wait for the end-line and >>>>> only then send this response? >>>>> Thanks in advance, >>>>> Gilad >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From Remi.Denis-Courmont@nokia.com Mon Feb 23 05:03:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883953A6A05 for ; Mon, 23 Feb 2009 05:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 oikdF-4dJMQj for ; Mon, 23 Feb 2009 05:03:05 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8C1E23A693B for ; Mon, 23 Feb 2009 05:03:05 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1ND2p4c020135; Mon, 23 Feb 2009 07:03:17 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 15:02:54 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 15:02:53 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n1ND2qIG015909; Mon, 23 Feb 2009 15:02:52 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: simple@ietf.org Date: Mon, 23 Feb 2009 15:03:06 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.27.15; KDE/4.1.4; i686; ; ) References: <431F8A31-54B9-4891-AD22-A1A528513674@estacado.net> <499C169D.6070005@colibria.com> In-Reply-To: <499C169D.6070005@colibria.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902231503.06828.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Feb 2009 13:02:53.0760 (UTC) FILETIME=[0A16F400:01C995B7] X-Nokia-AV: Clean Subject: Re: [Simple] MSRP (RFC 4975) question X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:03:06 -0000 Hello, On Wednesday 18 February 2009 16:09:33 ext Sebastian Dehne, you wrote: > One more thing: If the sender is currently busy transmitting a large > chunk and receives a 413 while during so, should A) the sender expect > another response for it's chunk (request) once he has sent the tail-line > and thus completed/interrupted this chunk? Or B) will the already > received 413 response count as a closure for the 'transaction'? Seriously, how could the answer be anything but B? Say the receiver sends a response while the chunk is not completed on its e= nd.=20 How does it determine that the chunk will not be completed at the other end= by=20 the time the response reaches the sender? TCP/IP does not support faster-th= an- light information conveyance in general and instantaneous transmission in=20 particular. Best regards, =2D-=20 R=E9mi Denis-Courmont From dehne@colibria.com Mon Feb 23 06:20:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC193A684D for ; Mon, 23 Feb 2009 06:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 VmPH0IwUwD0A for ; Mon, 23 Feb 2009 06:20:05 -0800 (PST) Received: from mail.colibria.com (pc2.colibria.com [194.143.13.66]) by core3.amsl.com (Postfix) with ESMTP id 64DBE3A67B6 for ; Mon, 23 Feb 2009 06:20:04 -0800 (PST) Received: from [192.168.1.183] (unknown [192.168.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.colibria.com (Postfix) with ESMTP id 99B89577B7; Mon, 23 Feb 2009 15:20:13 +0100 (CET) Message-ID: <49A2B09D.2090006@colibria.com> Date: Mon, 23 Feb 2009 15:20:13 +0100 From: Sebastian Dehne User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <431F8A31-54B9-4891-AD22-A1A528513674@estacado.net> <499C169D.6070005@colibria.com> <200902231503.06828.remi.denis-courmont@nokia.com> In-Reply-To: <200902231503.06828.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: simple@ietf.org Subject: Re: [Simple] MSRP (RFC 4975) question X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 14:20:06 -0000 Hi, Thanks for the response. I agree that B is the only option. Sebastian On 02/23/2009 02:03 PM, Rémi Denis-Courmont wrote: > Hello, > > On Wednesday 18 February 2009 16:09:33 ext Sebastian Dehne, you wrote: >> One more thing: If the sender is currently busy transmitting a large >> chunk and receives a 413 while during so, should A) the sender expect >> another response for it's chunk (request) once he has sent the tail-line >> and thus completed/interrupted this chunk? Or B) will the already >> received 413 response count as a closure for the 'transaction'? > > Seriously, how could the answer be anything but B? > > Say the receiver sends a response while the chunk is not completed on its end. > How does it determine that the chunk will not be completed at the other end by > the time the response reaches the sender? TCP/IP does not support faster-than- > light information conveyance in general and instantaneous transmission in > particular. > > Best regards, > From ben@estacado.net Mon Feb 23 08:35:03 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C983A6A6B for ; Mon, 23 Feb 2009 08:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 69UKsySK8Gp4 for ; Mon, 23 Feb 2009 08:35:03 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0596C3A698F for ; Mon, 23 Feb 2009 08:35:01 -0800 (PST) Received: from dn3-109.estacado.net (dn3-109.estacado.net [172.16.3.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1NGZAQ6043824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Feb 2009 10:35:11 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Christer Holmberg Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 10:35:10 -0600 X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:35:03 -0000 Hi, One other concern that occurred to me after I sent my recent comments is how the C-line connection model interacts with TLS. RFC 4975 encourages the use of TLS for authenticating the next hop, i.e. an MSRP relay, or even the MSRP peer when operating p2p. Sections 14.2 and 14.4 describe how MSRP ensures the connected device has the correct certificate. How would this work in the SBC/ALG scenario, where an SBC repoints the MSRP connection to itself? I think it depends on how the SBC treats TCP/TLS based media. If it simply relays the TLS handshake (similarly to an HTTPS proxy), then this may be okay. But if it terminates the TLS handshake itself, then things break. BTW, I think this concern also applies to the approach of having the SBC rewrite the path attribute instead of the C-line that I mentioned in a separate thread. Thanks! Ben. From ben@estacado.net Mon Feb 23 08:44:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5637028C115 for ; Mon, 23 Feb 2009 08:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 OlubFwoK2kMF for ; Mon, 23 Feb 2009 08:44:52 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0E2033A6ADA for ; Mon, 23 Feb 2009 08:44:51 -0800 (PST) Received: from dn3-109.estacado.net (dn3-109.estacado.net [172.16.3.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1NGj5pi045412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Feb 2009 10:45:05 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 10:45:05 -0600 References: X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: 2 Separate Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:44:53 -0000 On Feb 21, 2009, at 4:24 PM, Christer Holmberg wrote: > > Hi Ben, > >> I've been working through draft-ietf-simple-msrp-acm-00, and have a >> few > new thoughts about it. I am breaking these up into separate emails, to > try to avoid discussion thread confusion. >> >> I think we should be more clear on the separation between the COMEDIA > and the C-Line connection model bits of this draft. My understanding > is > that they are completely orthagonal, is this correct? Or does >> one require the other? >> >> From a process perspective, I don't think the COMEDIA bits are > controversial. I would even support those as MUST level updates to the > base MSRP spec. OTOH, I think the C-line connection part needs >> further discussion and work. > > The c-line connection part is optional, and the COMEDIA part can be > used > without it. Is it true the other way around? That is, can the c-line part be used without COMEDIA? I assume so, but if that is stated explicitly, I missed it. > > > I have tried to indicate that in a few places in the draft, but if you > think it needs to be further clarified I am happy to add/modify text. I see a "note" that the comedia part can be used without the c-line part late in the introduction. But the introduction still casts both mechanism as part of a singular "alternative connection model". I think it would be helpful to state something to the effect of the following early in the introduction: "This draft proposes two alternate mechanisms to the connection model defined in RFC 4975. The first is the use of COMEDIA to control the direction of the TCP connection. The second is the use of the SDP C-line to carry transport information for the TCP peer. These mechanisms can be used together, or independently of each other" Thanks, Ben. From HKaplan@acmepacket.com Mon Feb 23 09:38:37 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519E93A67DD for ; Mon, 23 Feb 2009 09:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] 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 0Xnt1IeRcUqs for ; Mon, 23 Feb 2009 09:38:36 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 722043A6359 for ; Mon, 23 Feb 2009 09:38:36 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 23 Feb 2009 12:37:32 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Feb 2009 12:37:31 -0500 From: Hadriel Kaplan To: Ben Campbell Date: Mon, 23 Feb 2009 12:37:31 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: AcmVXCwdAgAJKS7LRcWVdRkcjSlzsAAf8qQQ Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> In-Reply-To: <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:38:37 -0000 > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Sunday, February 22, 2009 9:14 PM > > I assume your old code already handles TCP based media? Yup. Many others' do as well. > You are correct, RFC 4975 currently says you match the entire MSRP URI > to the session, which includes the address and port, or conceivably a > host name and port. But if we updated that to only match on the > Session ID (i.e. that part of the URL right of the "/", it _might_ be > good enough. This would allow the session match to work even if the > address:port gets changed in flight. So now we're talking about changing the endpoints and the Relays, no? So t= hat doesn't jive with the idea of working with legacy RFC4975/6, does it? (= or am I missing something?) -hadriel From HKaplan@acmepacket.com Mon Feb 23 09:39:40 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB573A684E for ; Mon, 23 Feb 2009 09:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] 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 itGtObBmX6kk for ; Mon, 23 Feb 2009 09:39:40 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EF9253A6359 for ; Mon, 23 Feb 2009 09:39:39 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 23 Feb 2009 12:38:36 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Feb 2009 12:38:35 -0500 From: Hadriel Kaplan To: Ben Campbell , Christer Holmberg Date: Mon, 23 Feb 2009 12:38:35 -0500 Thread-Topic: [Simple] msrp-acm: TLS interaction Thread-Index: AcmV1IozZ9XsmqI3R+u02vK/CJNpJQACOtvA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:39:41 -0000 Presumably it would use RFC 4572, Comedia for TLS. -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Monday, February 23, 2009 11:35 AM > To: Christer Holmberg > Cc: Simple WG > Subject: [Simple] msrp-acm: TLS interaction > > Hi, > > One other concern that occurred to me after I sent my recent comments > is how the C-line connection model interacts with TLS. RFC 4975 > encourages the use of TLS for authenticating the next hop, i.e. an > MSRP relay, or even the MSRP peer when operating p2p. Sections 14.2 > and 14.4 describe how MSRP ensures the connected device has the > correct certificate. > > How would this work in the SBC/ALG scenario, where an SBC repoints the > MSRP connection to itself? I think it depends on how the SBC treats > TCP/TLS based media. If it simply relays the TLS handshake (similarly > to an HTTPS proxy), then this may be okay. But if it terminates the > TLS handshake itself, then things break. > > BTW, I think this concern also applies to the approach of having the > SBC rewrite the path attribute instead of the C-line that I mentioned > in a separate thread. > > Thanks! > > Ben. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Mon Feb 23 10:14:16 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F8B3A6359 for ; Mon, 23 Feb 2009 10:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 fthY+oqnjY+X for ; Mon, 23 Feb 2009 10:14:14 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 1864B3A6818 for ; Mon, 23 Feb 2009 10:14:12 -0800 (PST) Received: from dn3-109.estacado.net (dn3-109.estacado.net [172.16.3.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1NIEED6066369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Feb 2009 12:14:15 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 12:14:13 -0600 References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:14:16 -0000 On Feb 23, 2009, at 11:37 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Sunday, February 22, 2009 9:14 PM >> >> I assume your old code already handles TCP based media? > > Yup. Many others' do as well. > > >> You are correct, RFC 4975 currently says you match the entire MSRP >> URI >> to the session, which includes the address and port, or conceivably a >> host name and port. But if we updated that to only match on the >> Session ID (i.e. that part of the URL right of the "/", it _might_ be >> good enough. This would allow the session match to work even if the >> address:port gets changed in flight. > > So now we're talking about changing the endpoints and the Relays, > no? So that doesn't jive with the idea of working with legacy > RFC4975/6, does it? (or am I missing something?) It would not work with RFC4975/6 devices without a change. But then again, neither would the msrp-acm draft. > > > -hadriel From ben@estacado.net Mon Feb 23 10:21:27 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A9A3A6879 for ; Mon, 23 Feb 2009 10:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 lf-hXAE3Z33I for ; Mon, 23 Feb 2009 10:21:16 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id DEF713A6837 for ; Mon, 23 Feb 2009 10:21:15 -0800 (PST) Received: from dn3-109.estacado.net (dn3-109.estacado.net [172.16.3.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1NILR7m067531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Feb 2009 12:21:27 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 12:21:27 -0600 References: X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:21:27 -0000 On Feb 23, 2009, at 11:38 AM, Hadriel Kaplan wrote: > > Presumably it would use RFC 4572, Comedia for TLS. RFC 4975 already references 4572 for the fingerprint mechanism. My concern was not the passing of the fingerprint, but the introduction of an intermediary which is not likely to have a matching cert. This would be okay if the intermediary is transparent to the TLS handshake (which I think turn-tcp is, if I understand correctly), but not okay if the intermediary participates in the handshake. I don't know how SBCs typically handle TLS for media. In any case, the msrp-acm draft should probably address this. > > > -hadriel > > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Ben Campbell >> Sent: Monday, February 23, 2009 11:35 AM >> To: Christer Holmberg >> Cc: Simple WG >> Subject: [Simple] msrp-acm: TLS interaction >> >> Hi, >> >> One other concern that occurred to me after I sent my recent comments >> is how the C-line connection model interacts with TLS. RFC 4975 >> encourages the use of TLS for authenticating the next hop, i.e. an >> MSRP relay, or even the MSRP peer when operating p2p. Sections 14.2 >> and 14.4 describe how MSRP ensures the connected device has the >> correct certificate. >> >> How would this work in the SBC/ALG scenario, where an SBC repoints >> the >> MSRP connection to itself? I think it depends on how the SBC treats >> TCP/TLS based media. If it simply relays the TLS handshake (similarly >> to an HTTPS proxy), then this may be okay. But if it terminates the >> TLS handshake itself, then things break. >> >> BTW, I think this concern also applies to the approach of having the >> SBC rewrite the path attribute instead of the C-line that I mentioned >> in a separate thread. >> >> Thanks! >> >> Ben. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Mon Feb 23 10:26:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBE13A677C for ; Mon, 23 Feb 2009 10:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 S9donmhcbdpX for ; Mon, 23 Feb 2009 10:26:28 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ECF903A6359 for ; Mon, 23 Feb 2009 10:26:27 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 23 Feb 2009 13:25:24 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Feb 2009 13:25:23 -0500 From: Hadriel Kaplan To: Ben Campbell Date: Mon, 23 Feb 2009 13:25:23 -0500 Thread-Topic: [Simple] msrp-acm: TLS interaction Thread-Index: AcmV42Xm764JQuaAT5Sk8KOhSSY1oAAADjgQ Message-ID: References: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> In-Reply-To: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:26:29 -0000 Today SBC's typically are transparent, and let the TLS go end-end. They ha= ve no incentive to do otherwise, except for Lawful-intercept or content-sca= nning type reasons. But there is nothing to prevent them from being in the middle of it, since = they can replace the fingerprint all day long. -hadriel > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Monday, February 23, 2009 1:21 PM > To: Hadriel Kaplan > Cc: Christer Holmberg; Simple WG > Subject: Re: [Simple] msrp-acm: TLS interaction > > > On Feb 23, 2009, at 11:38 AM, Hadriel Kaplan wrote: > > > > > Presumably it would use RFC 4572, Comedia for TLS. > > RFC 4975 already references 4572 for the fingerprint mechanism. My > concern was not the passing of the fingerprint, but the introduction > of an intermediary which is not likely to have a matching cert. > > This would be okay if the intermediary is transparent to the TLS > handshake (which I think turn-tcp is, if I understand correctly), but > not okay if the intermediary participates in the handshake. I don't > know how SBCs typically handle TLS for media. > > In any case, the msrp-acm draft should probably address this. > > > > > > > -hadriel > > > > > >> -----Original Message----- > >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > >> Behalf > >> Of Ben Campbell > >> Sent: Monday, February 23, 2009 11:35 AM > >> To: Christer Holmberg > >> Cc: Simple WG > >> Subject: [Simple] msrp-acm: TLS interaction > >> > >> Hi, > >> > >> One other concern that occurred to me after I sent my recent comments > >> is how the C-line connection model interacts with TLS. RFC 4975 > >> encourages the use of TLS for authenticating the next hop, i.e. an > >> MSRP relay, or even the MSRP peer when operating p2p. Sections 14.2 > >> and 14.4 describe how MSRP ensures the connected device has the > >> correct certificate. > >> > >> How would this work in the SBC/ALG scenario, where an SBC repoints > >> the > >> MSRP connection to itself? I think it depends on how the SBC treats > >> TCP/TLS based media. If it simply relays the TLS handshake (similarly > >> to an HTTPS proxy), then this may be okay. But if it terminates the > >> TLS handshake itself, then things break. > >> > >> BTW, I think this concern also applies to the approach of having the > >> SBC rewrite the path attribute instead of the C-line that I mentioned > >> in a separate thread. > >> > >> Thanks! > >> > >> Ben. > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Mon Feb 23 11:14:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A16F28C0EB for ; Mon, 23 Feb 2009 11:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FvnCQ2P2Zkyk for ; Mon, 23 Feb 2009 11:14:30 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 50B1B28C0F2 for ; Mon, 23 Feb 2009 11:14:30 -0800 (PST) Received: from dn3-109.estacado.net (dn3-109.estacado.net [172.16.3.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1NJEf7s076024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Feb 2009 13:14:41 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <529135E1-8BFD-4CE2-9055-533747D6475A@estacado.net> From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 13:14:41 -0600 References: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:14:31 -0000 On Feb 23, 2009, at 12:25 PM, Hadriel Kaplan wrote: > > Today SBC's typically are transparent, and let the TLS go end-end. > They have no incentive to do otherwise, except for Lawful-intercept > or content-scanning type reasons. > > But there is nothing to prevent them from being in the middle of it, > since they can replace the fingerprint all day long. Ah, everything keeps coming back to that particular elephant (in the herd that has occupied the room) ;-) From a pragmatic perspective, I think it would help for the msrp-acm draft to capture this discussion in some form. > > > -hadriel > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Monday, February 23, 2009 1:21 PM >> To: Hadriel Kaplan >> Cc: Christer Holmberg; Simple WG >> Subject: Re: [Simple] msrp-acm: TLS interaction >> >> >> On Feb 23, 2009, at 11:38 AM, Hadriel Kaplan wrote: >> >>> >>> Presumably it would use RFC 4572, Comedia for TLS. >> >> RFC 4975 already references 4572 for the fingerprint mechanism. My >> concern was not the passing of the fingerprint, but the introduction >> of an intermediary which is not likely to have a matching cert. >> >> This would be okay if the intermediary is transparent to the TLS >> handshake (which I think turn-tcp is, if I understand correctly), but >> not okay if the intermediary participates in the handshake. I don't >> know how SBCs typically handle TLS for media. >> >> In any case, the msrp-acm draft should probably address this. >> >>> >>> >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf >>>> Of Ben Campbell >>>> Sent: Monday, February 23, 2009 11:35 AM >>>> To: Christer Holmberg >>>> Cc: Simple WG >>>> Subject: [Simple] msrp-acm: TLS interaction >>>> >>>> Hi, >>>> >>>> One other concern that occurred to me after I sent my recent >>>> comments >>>> is how the C-line connection model interacts with TLS. RFC 4975 >>>> encourages the use of TLS for authenticating the next hop, i.e. an >>>> MSRP relay, or even the MSRP peer when operating p2p. Sections 14.2 >>>> and 14.4 describe how MSRP ensures the connected device has the >>>> correct certificate. >>>> >>>> How would this work in the SBC/ALG scenario, where an SBC repoints >>>> the >>>> MSRP connection to itself? I think it depends on how the SBC treats >>>> TCP/TLS based media. If it simply relays the TLS handshake >>>> (similarly >>>> to an HTTPS proxy), then this may be okay. But if it terminates the >>>> TLS handshake itself, then things break. >>>> >>>> BTW, I think this concern also applies to the approach of having >>>> the >>>> SBC rewrite the path attribute instead of the C-line that I >>>> mentioned >>>> in a separate thread. >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple > From christer.holmberg@ericsson.com Tue Feb 24 03:44:05 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E433A69C7 for ; Tue, 24 Feb 2009 03:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 E0DUWY4Jeb5P for ; Tue, 24 Feb 2009 03:44:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D0D373A67FD for ; Tue, 24 Feb 2009 03:44:03 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EECF72066D; Tue, 24 Feb 2009 12:44:20 +0100 (CET) X-AuditID: c1b4fb3e-ab0b9bb000001315-2b-49a3dd94ddcf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C378020592; Tue, 24 Feb 2009 12:44:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 12:44:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 12:44:19 +0100 Message-ID: In-Reply-To: <529135E1-8BFD-4CE2-9055-533747D6475A@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm: TLS interaction thread-index: AcmV6v3mHcnptKfvTuOZEz8r5weuUgAidcig References: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> <529135E1-8BFD-4CE2-9055-533747D6475A@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , "Hadriel Kaplan" X-OriginalArrivalTime: 24 Feb 2009 11:44:20.0883 (UTC) FILETIME=[3B68BE30:01C99675] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 11:44:05 -0000 Hi, I think we can add some text sayin that an SBC which performes "TCP/IP level actions", e.g. NAT traversal, gating, bandwidth policing etc, can be TLS transparent, while an SBC which performs LI, content screening etc would either have to reject the TLS usage, OR act as a TLS B2BUA. Regards, Christer=20 -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Monday, February 23, 2009 9:15 PM To: Hadriel Kaplan Cc: Christer Holmberg; Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction On Feb 23, 2009, at 12:25 PM, Hadriel Kaplan wrote: > > Today SBC's typically are transparent, and let the TLS go end-end. =20 > They have no incentive to do otherwise, except for Lawful-intercept or > content-scanning type reasons. > > But there is nothing to prevent them from being in the middle of it,=20 > since they can replace the fingerprint all day long. Ah, everything keeps coming back to that particular elephant (in the herd that has occupied the room) ;-) From a pragmatic perspective, I think it would help for the msrp-acm draft to capture this discussion in some form. > > > -hadriel > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Monday, February 23, 2009 1:21 PM >> To: Hadriel Kaplan >> Cc: Christer Holmberg; Simple WG >> Subject: Re: [Simple] msrp-acm: TLS interaction >> >> >> On Feb 23, 2009, at 11:38 AM, Hadriel Kaplan wrote: >> >>> >>> Presumably it would use RFC 4572, Comedia for TLS. >> >> RFC 4975 already references 4572 for the fingerprint mechanism. My=20 >> concern was not the passing of the fingerprint, but the introduction=20 >> of an intermediary which is not likely to have a matching cert. >> >> This would be okay if the intermediary is transparent to the TLS=20 >> handshake (which I think turn-tcp is, if I understand correctly), but >> not okay if the intermediary participates in the handshake. I don't=20 >> know how SBCs typically handle TLS for media. >> >> In any case, the msrp-acm draft should probably address this. >> >>> >>> >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>> Behalf Of Ben Campbell >>>> Sent: Monday, February 23, 2009 11:35 AM >>>> To: Christer Holmberg >>>> Cc: Simple WG >>>> Subject: [Simple] msrp-acm: TLS interaction >>>> >>>> Hi, >>>> >>>> One other concern that occurred to me after I sent my recent=20 >>>> comments is how the C-line connection model interacts with TLS. RFC >>>> 4975 encourages the use of TLS for authenticating the next hop,=20 >>>> i.e. an MSRP relay, or even the MSRP peer when operating p2p.=20 >>>> Sections 14.2 and 14.4 describe how MSRP ensures the connected=20 >>>> device has the correct certificate. >>>> >>>> How would this work in the SBC/ALG scenario, where an SBC repoints=20 >>>> the MSRP connection to itself? I think it depends on how the SBC=20 >>>> treats TCP/TLS based media. If it simply relays the TLS handshake=20 >>>> (similarly to an HTTPS proxy), then this may be okay. But if it=20 >>>> terminates the TLS handshake itself, then things break. >>>> >>>> BTW, I think this concern also applies to the approach of having=20 >>>> the SBC rewrite the path attribute instead of the C-line that I=20 >>>> mentioned in a separate thread. >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple > From christer.holmberg@ericsson.com Tue Feb 24 06:01:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2C03A6970 for ; Tue, 24 Feb 2009 06:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.506 X-Spam-Level: X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 UWfXg-1acoqL for ; Tue, 24 Feb 2009 06:01:06 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4B70A3A6872 for ; Tue, 24 Feb 2009 06:01:05 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDD9A21E62; Tue, 24 Feb 2009 15:01:22 +0100 (CET) X-AuditID: c1b4fb3c-a827fbb00000127c-a7-49a3ebd45d83 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD09223408; Tue, 24 Feb 2009 13:45:08 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 13:45:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 13:45:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs thread-index: AcmV4o4/OgCTqte9Tpm/ogv/xSQpowAms0dw References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" , "Hadriel Kaplan" X-OriginalArrivalTime: 24 Feb 2009 12:45:08.0391 (UTC) FILETIME=[B97E4B70:01C9967D] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:01:07 -0000 Hi, Maybe we should just live with the fact that it doesn=B4t work with = relays, and a receiving entity which wants to use relays should reject = the msrp-acm offer. As Hadriel said, an SBC operator most likely = requires all the traffic to pass the SBC, so legacy MSRP usage would not = work anyway. >From my experience, people asking for MSRP wants the acm solution, = because they want it to work with their SBCs, in order to anchor the = MSRP "media" (for whatever policy etc reasons). I haven't heard about = anyone asking for MSRP relays. And, since the number of deployed MSRP relays seems to be very small, it = probably wouldn't cause any major real-life problems. So, if we get this done, I think people will switch to msrp-acm. Regards, Christer =20 -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Monday, February 23, 2009 8:14 PM To: Hadriel Kaplan Cc: Simple WG; Christer Holmberg Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs On Feb 23, 2009, at 11:37 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Sunday, February 22, 2009 9:14 PM >> >> I assume your old code already handles TCP based media? > > Yup. Many others' do as well. > > >> You are correct, RFC 4975 currently says you match the entire MSRP=20 >> URI to the session, which includes the address and port, or=20 >> conceivably a host name and port. But if we updated that to only=20 >> match on the Session ID (i.e. that part of the URL right of the "/",=20 >> it _might_ be good enough. This would allow the session match to work = >> even if the address:port gets changed in flight. > > So now we're talking about changing the endpoints and the Relays, no? = > So that doesn't jive with the idea of working with legacy RFC4975/6,=20 > does it? (or am I missing something?) It would not work with RFC4975/6 devices without a change. But then = again, neither would the msrp-acm draft. > > > -hadriel From ben@estacado.net Tue Feb 24 06:31:08 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DC228C0CE for ; Tue, 24 Feb 2009 06:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 dp7AhXufWAay for ; Tue, 24 Feb 2009 06:31:07 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 97E373A69BB for ; Tue, 24 Feb 2009 06:31:01 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1OEV9fg068653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Feb 2009 08:31:14 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <9AAC6B3E-89DF-48EB-BAF5-9EF21D7C2D04@estacado.net> From: Ben Campbell To: "Christer Holmberg" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 08:31:10 -0600 References: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> <529135E1-8BFD-4CE2-9055-533747D6475A@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:31:08 -0000 On Feb 24, 2009, at 5:44 AM, Christer Holmberg wrote: > > Hi, > > I think we can add some text sayin that an SBC which performes "TCP/IP > level actions", e.g. NAT traversal, gating, bandwidth policing etc, > can > be TLS transparent, while an SBC which performs LI, content screening > etc would either have to reject the TLS usage, OR act as a TLS B2BUA. I suggest generalizing this, and saying that it applies to TCP level intermediary in the media path. Also, in the case of acting as a TLS B2BUA, it's worth mentioning that doing this may lead the users to believe they have an e2e secure channel when in fact they do not. It would be preferable to reject the TLS usage rather than misinform the users about the security properties of their session. > > > Regards, > > Christer > > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Monday, February 23, 2009 9:15 PM > To: Hadriel Kaplan > Cc: Christer Holmberg; Simple WG > Subject: Re: [Simple] msrp-acm: TLS interaction > > > On Feb 23, 2009, at 12:25 PM, Hadriel Kaplan wrote: > >> >> Today SBC's typically are transparent, and let the TLS go end-end. >> They have no incentive to do otherwise, except for Lawful-intercept >> or > >> content-scanning type reasons. >> >> But there is nothing to prevent them from being in the middle of it, >> since they can replace the fingerprint all day long. > > Ah, everything keeps coming back to that particular elephant (in the > herd that has occupied the room) ;-) > > From a pragmatic perspective, I think it would help for the msrp-acm > draft to capture this discussion in some form. > > >> >> >> -hadriel >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@estacado.net] >>> Sent: Monday, February 23, 2009 1:21 PM >>> To: Hadriel Kaplan >>> Cc: Christer Holmberg; Simple WG >>> Subject: Re: [Simple] msrp-acm: TLS interaction >>> >>> >>> On Feb 23, 2009, at 11:38 AM, Hadriel Kaplan wrote: >>> >>>> >>>> Presumably it would use RFC 4572, Comedia for TLS. >>> >>> RFC 4975 already references 4572 for the fingerprint mechanism. My >>> concern was not the passing of the fingerprint, but the introduction >>> of an intermediary which is not likely to have a matching cert. >>> >>> This would be okay if the intermediary is transparent to the TLS >>> handshake (which I think turn-tcp is, if I understand correctly), >>> but > >>> not okay if the intermediary participates in the handshake. I don't >>> know how SBCs typically handle TLS for media. >>> >>> In any case, the msrp-acm draft should probably address this. >>> >>>> >>>> >>>> -hadriel >>>> >>>> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>>> Behalf Of Ben Campbell >>>>> Sent: Monday, February 23, 2009 11:35 AM >>>>> To: Christer Holmberg >>>>> Cc: Simple WG >>>>> Subject: [Simple] msrp-acm: TLS interaction >>>>> >>>>> Hi, >>>>> >>>>> One other concern that occurred to me after I sent my recent >>>>> comments is how the C-line connection model interacts with TLS. >>>>> RFC > >>>>> 4975 encourages the use of TLS for authenticating the next hop, >>>>> i.e. an MSRP relay, or even the MSRP peer when operating p2p. >>>>> Sections 14.2 and 14.4 describe how MSRP ensures the connected >>>>> device has the correct certificate. >>>>> >>>>> How would this work in the SBC/ALG scenario, where an SBC repoints >>>>> the MSRP connection to itself? I think it depends on how the SBC >>>>> treats TCP/TLS based media. If it simply relays the TLS handshake >>>>> (similarly to an HTTPS proxy), then this may be okay. But if it >>>>> terminates the TLS handshake itself, then things break. >>>>> >>>>> BTW, I think this concern also applies to the approach of having >>>>> the SBC rewrite the path attribute instead of the C-line that I >>>>> mentioned in a separate thread. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >> > From ben@estacado.net Tue Feb 24 06:34:23 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2ED43A6A1E for ; Tue, 24 Feb 2009 06:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 MtumXC672xmZ for ; Tue, 24 Feb 2009 06:34:22 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 6CC553A68D3 for ; Tue, 24 Feb 2009 06:34:22 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1OEYVR6069195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Feb 2009 08:34:35 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> From: Ben Campbell To: "Christer Holmberg" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 08:34:31 -0600 References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:34:23 -0000 On Feb 24, 2009, at 6:45 AM, Christer Holmberg wrote: > > Hi, > > Maybe we should just live with the fact that it doesn=B4t work with =20= > relays, and a receiving entity which wants to use relays should =20 > reject the msrp-acm offer. As Hadriel said, an SBC operator most =20 > likely requires all the traffic to pass the SBC, so legacy MSRP =20 > usage would not work anyway. I'm not sure I agree. It seems like that takes us from "probably won't =20= interoperate" to "definitely won't interoperate." > > > =46rom my experience, people asking for MSRP wants the acm solution, =20= > because they want it to work with their SBCs, in order to anchor the =20= > MSRP "media" (for whatever policy etc reasons). I haven't heard =20 > about anyone asking for MSRP relays. > > And, since the number of deployed MSRP relays seems to be very =20 > small, it probably wouldn't cause any major real-life problems. > > So, if we get this done, I think people will switch to msrp-acm. This quickly returns to the "if we go down this path, we have =20 effectively deprecated MSRP relays." situation. If the community =20 wants to do that, so be it. But I really don't want to split the =20 standard so that we have two implementation choices that can't =20 interoperate. > > > Regards, > > Christer > > > > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Monday, February 23, 2009 8:14 PM > To: Hadriel Kaplan > Cc: Simple WG; Christer Holmberg > Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs > > > On Feb 23, 2009, at 11:37 AM, Hadriel Kaplan wrote: > >> >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@estacado.net] >>> Sent: Sunday, February 22, 2009 9:14 PM >>> >>> I assume your old code already handles TCP based media? >> >> Yup. Many others' do as well. >> >> >>> You are correct, RFC 4975 currently says you match the entire MSRP >>> URI to the session, which includes the address and port, or >>> conceivably a host name and port. But if we updated that to only >>> match on the Session ID (i.e. that part of the URL right of the "/", >>> it _might_ be good enough. This would allow the session match to =20 >>> work >>> even if the address:port gets changed in flight. >> >> So now we're talking about changing the endpoints and the Relays, no? >> So that doesn't jive with the idea of working with legacy RFC4975/6, >> does it? (or am I missing something?) > > It would not work with RFC4975/6 devices without a change. But then =20= > again, neither would the msrp-acm draft. > >> >> >> -hadriel > From ag@ag-projects.com Tue Feb 24 08:36:44 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1083A6B3D for ; Tue, 24 Feb 2009 08:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 jEPbu5khLqdD for ; Tue, 24 Feb 2009 08:36:44 -0800 (PST) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 959733A6B3A for ; Tue, 24 Feb 2009 08:36:42 -0800 (PST) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1Lc0BP-0007aJ-SR for simple@ietf.org; Tue, 24 Feb 2009 17:31:02 +0100 Message-Id: From: Adrian Georgescu To: simple@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-12--511825133 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 17:36:52 +0100 References: X-Mailer: Apple Mail (2.930.3) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: [Simple] RFC 4976 is a well defined standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:36:44 -0000 --Apple-Mail-12--511825133 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, As the maintainer of the MSRP relay open source project I completely disagree with the idea of deprecating RFC 4976. The open source MSRP relay serves now a +50,000 user base of at http://sip2sip.info and made possible new SIP applications that were not envisaged before like desktop sharing. The fact that commercially speaking the MSRP relay does not appeal to some SBC vendors cannot constitute a reason for deprecating a standard. I have found no technical issues with the deployment of the relay in the last 12 months of operations. The fact that not many people talk about it on discussion lists does not mean that is not working or that is an irrelevant topic. The software simply works and RFC 4976 is good example of well designed IETF standard. Yours sincerely, Adrian Georgescu AG Projects --Apple-Mail-12--511825133 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable http://sip2sip.info and made possible = new SIP applications that were not envisaged before like desktop = sharing.

The fact = that commercially speaking the MSRP relay does not appeal to = some SBC vendors cannot constitute a reason for deprecating a = standard. I have found no technical issues with the deployment of = the relay in the last 12 months of = operations. 

The fact that not many people = talk about it on discussion lists does not mean that is not working or = that is an irrelevant topic.

The software = simply works and RFC 4976 is good example of well designed IETF = standard. 

Yours = sincerely,
Adrian Georgescu
AG = Projects

= --Apple-Mail-12--511825133-- From ben@estacado.net Tue Feb 24 10:36:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5914528C24F for ; Tue, 24 Feb 2009 10:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rWYueQy6E+y2 for ; Tue, 24 Feb 2009 10:36:30 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 9DD863A6982 for ; Tue, 24 Feb 2009 10:36:29 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n1OIaVg1094826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Feb 2009 12:36:38 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Adrian Georgescu In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3--504646334 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 12:36:31 -0600 References: X-Mailer: Apple Mail (2.930.3) Cc: simple@ietf.org Subject: Re: [Simple] RFC 4976 is a well defined standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:36:31 -0000 --Apple-Mail-3--504646334 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks, Adrian. I was the one who mentioned deprecation. I don't think anyone else has mentioned officially deprecating it per se. Just to be clear, I don't _want_ to deprecate it, but I am afraid that the current proposals to create a SBC/ALG friendly alternative would effectively split MSRP implementations into two "profiles" that won't talk to each other. If there were no deployments of RFC 4976, it might have made sense to just move on and update MSRP to follow the proposed c-line mechanism in Christer's draft. But given the sip2sip user base, it's pretty clear that market demand for 4976 does exist. So, I am in favor of work to make MSRP work better in the presence of SBCs/ALGs, but I believe that any such effort _must_ allow endpoints behind SBCs to interoperate with peers that are behind MSRP relays. On Feb 24, 2009, at 10:36 AM, Adrian Georgescu wrote: > Hello, > > As the maintainer of the MSRP relay open source project I completely > disagree with the idea of deprecating RFC 4976. The open source MSRP > relay serves now a +50,000 user base of at http://sip2sip.info and > made possible new SIP applications that were not envisaged before > like desktop sharing. > > The fact that commercially speaking the MSRP relay does not appeal > to some SBC vendors cannot constitute a reason for deprecating a > standard. I have found no technical issues with the deployment of > the relay in the last 12 months of operations. > > The fact that not many people talk about it on discussion lists does > not mean that is not working or that is an irrelevant topic. > > The software simply works and RFC 4976 is good example of well > designed IETF standard. > > Yours sincerely, > Adrian Georgescu > AG Projects > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-3--504646334 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Thanks, = Adrian.

I was the one who mentioned = deprecation. I don't think anyone else has mentioned officially = deprecating it per se. Just to be clear, I don't _want_ to deprecate it, = but I am afraid that the current proposals to create a SBC/ALG friendly = alternative would effectively split MSRP implementations into two = "profiles" that won't talk to each other. If there were no deployments = of RFC 4976, it might have made sense to just move on and update MSRP to = follow the proposed c-line mechanism in Christer's = draft.

But given the sip2sip user base, it's = pretty clear that market demand for 4976 does = exist.

So, I am in favor of work to make MSRP = work better in the presence of SBCs/ALGs, but I believe that any such = effort _must_ allow endpoints behind SBCs to interoperate with peers = that are behind MSRP relays. 

On Feb 24, 2009, = at 10:36 AM, Adrian Georgescu wrote:

http://sip2sip.info and made possible = new SIP applications that were not envisaged before like desktop = sharing.

The fact = that commercially speaking the MSRP relay does not appeal to = some SBC vendors cannot constitute a reason for deprecating a = standard. I have found no technical issues with the deployment of = the relay in the last 12 months of = operations. 

The fact that not many people = talk about it on discussion lists does not mean that is not working or = that is an irrelevant topic.

The software = simply works and RFC 4976 is good example of well designed IETF = standard. 

Yours = sincerely,
Adrian Georgescu
AG = Projects

_______________________________________= ________
Simple mailing list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail-3--504646334-- From HKaplan@acmepacket.com Tue Feb 24 12:38:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7A23A697D for ; Tue, 24 Feb 2009 12:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VsdePd1T3R9o for ; Tue, 24 Feb 2009 12:38:21 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D57413A694F for ; Tue, 24 Feb 2009 12:38:20 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 24 Feb 2009 15:37:16 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Feb 2009 15:37:16 -0500 From: Hadriel Kaplan To: Adrian Georgescu , "simple@ietf.org" Date: Tue, 24 Feb 2009 15:37:15 -0500 Thread-Topic: [Simple] RFC 4976 is a well defined standard Thread-Index: AcmWnf5AOZUzBPu4R7SmNRbjuDNQxgAHJpLQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC313FD850994mail_" MIME-Version: 1.0 Subject: Re: [Simple] RFC 4976 is a well defined standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:38:25 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC313FD850994mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, I did not and was not advocating deprecating RFC 4976. We could argue abou= t the relative success of it, in the grand scheme of things, but it would n= ot be productive. All we're arguing about is whether an alternative connec= tion and deployment model needs to interwork with MSRP Relays, or not. Since AG-Projects' msrprelay.org project is as far as I know the canonical = example of an actual MSRP Relay, what do you think? Do you care? -hadriel ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Adrian Georgescu Sent: Tuesday, February 24, 2009 11:37 AM As the maintainer of the MSRP relay open source project I completely disagr= ee with the idea of deprecating RFC 4976. The open source MSRP relay serves= now a +50,000 user base of at http://sip2sip.info and made possible new SI= P applications that were not envisaged before like desktop sharing. The fact that commercially speaking the MSRP relay does not appeal to some = SBC vendors cannot constitute a reason for deprecating a standard. I have f= ound no technical issues with the deployment of the relay in the last 12 mo= nths of operations. The fact that not many people talk about it on discussion lists does not me= an that is not working or that is an irrelevant topic. The software simply works and RFC 4976 is good example of well designed IET= F standard. Yours sincerely, Adrian Georgescu AG Projects --_000_E6C2E8958BA59A4FB960963D475F7AC313FD850994mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian,

I did not and was not advocating deprecating RFC 4976.  We could argue about the relative success of it= , in the grand scheme of things, but it would not be productive.  All we= 217;re arguing about is whether an alternative connection and deployment model nee= ds to interwork with MSRP Relays, or not.

 

Since AG-Projects’ msrprelay.org project is as far as I know the canonical example of an actual MSRP Relay, = what do you think?  Do you care?

 

-hadriel

 

From: simple-b= ounces@ietf.org [mailto:simple-bounces@ietf.org] On Beh= alf Of Adrian Georgescu
Sent: Tuesday, February 24, = 2009 11:37 AM

As the maintainer of the MSRP relay open source project I completely disagree with the idea of deprecating RFC 4976. T= he open source MSRP relay serves now a +50,000 user base of at http://sip2sip.info and made possible new = SIP applications that were not envisaged before like desktop sharing.

The fact that commercially speaking the MSRP relay does n= ot appeal to some SBC vendors cannot constitute a reason for deprecating a standard. I have found no technical issues with the deployment of the relay in the last 12 months of operations. 

The fact that not many people talk about it on discussion lists doe= s not mean that is not working or that is an irrelevant topic.

The software simply works and RFC 4976 is good example of well desi= gned IETF standard. 

Yours sincerely,

Adrian Georgescu

AG Projects

 

--_000_E6C2E8958BA59A4FB960963D475F7AC313FD850994mail_-- From christer.holmberg@ericsson.com Tue Feb 24 12:56:18 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C2B3A6403 for ; Tue, 24 Feb 2009 12:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.54 X-Spam-Level: X-Spam-Status: No, score=-5.54 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 i3BP7xawonjv for ; Tue, 24 Feb 2009 12:56:17 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CD7303A6934 for ; Tue, 24 Feb 2009 12:56:16 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D97BA2045D; Tue, 24 Feb 2009 21:56:29 +0100 (CET) X-AuditID: c1b4fb3c-aa283bb00000127c-97-49a45efd4ef3 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A4ADB20422; Tue, 24 Feb 2009 21:56:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 21:56:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 21:56:28 +0100 Message-ID: In-Reply-To: <9AAC6B3E-89DF-48EB-BAF5-9EF21D7C2D04@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm: TLS interaction thread-index: AcmWjJFC1LoqCd8RQ7mhn1D/Ojp3SwANOs0g References: <09163B01-BDA6-4E37-8C05-E19C11F1FA22@estacado.net> <529135E1-8BFD-4CE2-9055-533747D6475A@estacado.net> <9AAC6B3E-89DF-48EB-BAF5-9EF21D7C2D04@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 24 Feb 2009 20:56:29.0786 (UTC) FILETIME=[5DC62BA0:01C996C2] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm: TLS interaction X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:56:18 -0000 Hi,=20 >>I think we can add some text sayin that an SBC which performes "TCP/IP >>level actions", e.g. NAT traversal, gating, bandwidth policing etc,=20 >>can be TLS transparent, while an SBC which performs LI, content=20 >>screening etc would either have to reject the TLS usage, OR act as a=20 >>TLS B2BUA. > >I suggest generalizing this, and saying that it applies to TCP level intermediary in the media path. Sure, we can do that. >Also, in the case of acting as a TLS B2BUA, it's worth mentioning that doing this may lead the users to believe they have an e2e secure channel when in fact they do not. Yes. >It would be preferable to reject the TLS usage rather than misinform the users about the security properties of their session. I am not sure we should say so much about the preferred way. First, it doesn't only affect MSRP. Second, at the end of the day I assume it's going to be based on operator policy etc whether TLS is rejected or not, no matter what we write. But, I do think we should mention the fact that a TLS B2BUA leads users to believe that they have an e2e secure channel, to make "policy makers" aware of it. Regards, Christer > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Monday, February 23, 2009 9:15 PM > To: Hadriel Kaplan > Cc: Christer Holmberg; Simple WG > Subject: Re: [Simple] msrp-acm: TLS interaction > > > On Feb 23, 2009, at 12:25 PM, Hadriel Kaplan wrote: > >> >> Today SBC's typically are transparent, and let the TLS go end-end. >> They have no incentive to do otherwise, except for Lawful-intercept=20 >> or > >> content-scanning type reasons. >> >> But there is nothing to prevent them from being in the middle of it,=20 >> since they can replace the fingerprint all day long. > > Ah, everything keeps coming back to that particular elephant (in the=20 > herd that has occupied the room) ;-) > > From a pragmatic perspective, I think it would help for the msrp-acm=20 > draft to capture this discussion in some form. > > >> >> >> -hadriel >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@estacado.net] >>> Sent: Monday, February 23, 2009 1:21 PM >>> To: Hadriel Kaplan >>> Cc: Christer Holmberg; Simple WG >>> Subject: Re: [Simple] msrp-acm: TLS interaction >>> >>> >>> On Feb 23, 2009, at 11:38 AM, Hadriel Kaplan wrote: >>> >>>> >>>> Presumably it would use RFC 4572, Comedia for TLS. >>> >>> RFC 4975 already references 4572 for the fingerprint mechanism. My=20 >>> concern was not the passing of the fingerprint, but the introduction >>> of an intermediary which is not likely to have a matching cert. >>> >>> This would be okay if the intermediary is transparent to the TLS=20 >>> handshake (which I think turn-tcp is, if I understand correctly),=20 >>> but > >>> not okay if the intermediary participates in the handshake. I don't=20 >>> know how SBCs typically handle TLS for media. >>> >>> In any case, the msrp-acm draft should probably address this. >>> >>>> >>>> >>>> -hadriel >>>> >>>> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>>> Behalf Of Ben Campbell >>>>> Sent: Monday, February 23, 2009 11:35 AM >>>>> To: Christer Holmberg >>>>> Cc: Simple WG >>>>> Subject: [Simple] msrp-acm: TLS interaction >>>>> >>>>> Hi, >>>>> >>>>> One other concern that occurred to me after I sent my recent=20 >>>>> comments is how the C-line connection model interacts with TLS. >>>>> RFC > >>>>> 4975 encourages the use of TLS for authenticating the next hop,=20 >>>>> i.e. an MSRP relay, or even the MSRP peer when operating p2p. >>>>> Sections 14.2 and 14.4 describe how MSRP ensures the connected=20 >>>>> device has the correct certificate. >>>>> >>>>> How would this work in the SBC/ALG scenario, where an SBC repoints >>>>> the MSRP connection to itself? I think it depends on how the SBC=20 >>>>> treats TCP/TLS based media. If it simply relays the TLS handshake=20 >>>>> (similarly to an HTTPS proxy), then this may be okay. But if it=20 >>>>> terminates the TLS handshake itself, then things break. >>>>> >>>>> BTW, I think this concern also applies to the approach of having=20 >>>>> the SBC rewrite the path attribute instead of the C-line that I=20 >>>>> mentioned in a separate thread. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >> > From ag@ag-projects.com Tue Feb 24 13:31:23 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2025828C10C for ; Tue, 24 Feb 2009 13:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RRW0vqd5pgaV for ; Tue, 24 Feb 2009 13:31:21 -0800 (PST) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 6739E28C102 for ; Tue, 24 Feb 2009 13:31:20 -0800 (PST) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.128]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1Lc4mR-0002FO-GW; Tue, 24 Feb 2009 22:25:36 +0100 Message-Id: From: Adrian Georgescu To: Hadriel Kaplan In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--494153445 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 22:31:24 +0100 References: X-Mailer: Apple Mail (2.930.3) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Cc: "simple@ietf.org" Subject: Re: [Simple] RFC 4976 is a well defined standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:31:23 -0000 --Apple-Mail-2--494153445 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Hadriel, One property of MSRP protocol and its relay extension is that is a =20 straight forward standard with no choices. Now hypothetically if I =20 would be again at the decision point to implement a NAT traversal =20 solution with two or more possible IETF ways to do it, I would =20 probably give up as I would not have an idea which choice is better =20 long term and it would be difficult to ask customers for a choice =20 either. Same dilema will be faced by any developer or operations =20 manager as the modes are mutually exclusive. If this draft helps your company sell more boxes then I guess is for =20 you worth pursuing, personally I do not see a good reason to create =20 now in 2009 yet another backwards incompatible standard for NAT =20 traversal for MSRP. There is a saying that if you want to kill something just add choices, =20= people will get bogged down in choosing and arguing forever and little =20= will get done. Adrian On Feb 24, 2009, at 9:37 PM, Hadriel Kaplan wrote: > Hi Adrian, > I did not and was not advocating deprecating RFC 4976. We could =20 > argue about the relative success of it, in the grand scheme of =20 > things, but it would not be productive. All we=92re arguing about is =20= > whether an alternative connection and deployment model needs to =20 > interwork with MSRP Relays, or not. > > Since AG-Projects=92 msrprelay.org project is as far as I know the =20 > canonical example of an actual MSRP Relay, what do you think? Do =20 > you care? > > -hadriel > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On =20 > Behalf Of Adrian Georgescu > Sent: Tuesday, February 24, 2009 11:37 AM > > As the maintainer of the MSRP relay open source project I completely =20= > disagree with the idea of deprecating RFC 4976. The open source MSRP =20= > relay serves now a +50,000 user base of at http://sip2sip.info and =20 > made possible new SIP applications that were not envisaged before =20 > like desktop sharing. > The fact that commercially speaking the MSRP relay does not appeal =20 > to some SBC vendors cannot constitute a reason for deprecating a =20 > standard. I have found no technical issues with the deployment of =20 > the relay in the last 12 months of operations. > The fact that not many people talk about it on discussion lists does =20= > not mean that is not working or that is an irrelevant topic. > The software simply works and RFC 4976 is good example of well =20 > designed IETF standard. > Yours sincerely, > Adrian Georgescu > AG Projects > --Apple-Mail-2--494153445 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi = Hadriel,

One property of MSRP protocol and its = relay extension is that is a straight forward standard with no choices. = Now hypothetically if I would be again at the decision point = to implement a NAT traversal solution with two or more possible IETF = ways to do it, I would probably give up as I would not have an idea = which choice is better long term and it would be difficult to ask = customers for a choice either. Same dilema will be faced by any = developer or operations manager as the modes are mutually = exclusive.

If this draft helps your company = sell more boxes then I guess is for you worth pursuing, personally I do = not see a good reason to create now in 2009 yet another backwards = incompatible standard for NAT traversal for = MSRP.

There is a saying that if you want to = kill something just add choices, people will get bogged down = in choosing and arguing forever and little will get = done.

Adrian

On = Feb 24, 2009, at 9:37 PM, Hadriel Kaplan wrote:

Hi = Adrian,
I did not and was not advocating deprecating RFC = 4976.  We could argue about the relative success of it, in the = grand scheme of things, but it would not be productive.  All we=92re = arguing about is whether an alternative connection and deployment model = needs to interwork with MSRP Relays, or = not.
 
Since = AG-Projects=92 msrprelay.org project is as far as I know the canonical = example of an actual MSRP Relay, what do you think?  Do you = care?
 
 
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adrian = Georgescu
 Tuesday, February 24, 2009 = 11:37 AM

As the maintainer of the MSRP relay open = source project I completely disagree with the idea of = deprecating RFC 4976. The open source MSRP relay serves now a = +50,000 user base of at http://sip2sip.info and made possible new SIP = applications that were not envisaged before like desktop = sharing.
The fact = that commercially speaking the MSRP relay does not appeal to = some SBC vendors cannot constitute a reason for deprecating a = standard. I have found no technical issues with the deployment of = the relay in the last 12 months of = operations. 
The fact that not many people talk about it = on discussion lists does not mean that is not working or that is an = irrelevant topic.
The software simply works and RFC 4976 is = good example of well designed IETF = standard. 
Yours = sincerely,
Adrian = Georgescu
AG = Projects
In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RFC 4976 is a well defined standard thread-index: AcmWx1ybMtbMeyUUSfa2C6lQhxFHnQAACq9g References: From: "Christer Holmberg" To: "Adrian Georgescu" , "Hadriel Kaplan" X-OriginalArrivalTime: 24 Feb 2009 21:42:59.0847 (UTC) FILETIME=[DCC7B170:01C996C8] X-Brightmail-Tracker: AAAAAA== Cc: simple@ietf.org Subject: Re: [Simple] RFC 4976 is a well defined standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:42:43 -0000 Hi,=20 First, I am not saying we should deprecate RFC 4976 either. I also think the question is whether we require interoperability with users behind relays. Currently nodes behind SBCs in many cases won't be able to communicate with anyone (including sip2sip.info users), and for the MSRP protocol I think that is much worse than having some use-cases which may not work. It's not only about making a few SBC vendors happy. >One property of MSRP protocol and its relay extension is that is a straight forward standard with no choices. Now hypothetically if I would be again at the decision point to implement a NAT traversal=20 >solution with two or more possible IETF ways to do it, I would probably give up as I would not have an idea which choice is better long term and it would be difficult to ask customers for a choice=20 >either. Same dilema will be faced by any developer or operations manager as the modes are mutually exclusive. > >If this draft helps your company sell more boxes then I guess is for you worth pursuing, personally I do not see a good reason to create now in 2009 yet another backwards incompatible standard for NAT=20 >traversal for MSRP. You don't need to create a new NAT traversal standard - you can use existing ones. Regards, Christer Hi Adrian, I did not and was not advocating deprecating RFC 4976. We could argue about the relative success of it, in the grand scheme of things, but it would not be productive. All we're arguing about is whether an alternative connection and deployment model needs to interwork with MSRP Relays, or not. Since AG-Projects' msrprelay.org project is as far as I know the canonical example of an actual MSRP Relay, what do you think? Do you care? -hadriel ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adrian Georgescu Sent: Tuesday, February 24, 2009 11:37 AM =09 =09 As the maintainer of the MSRP relay open source project I completely disagree with the idea of deprecating RFC 4976. The open source MSRP relay serves now a +50,000 user base of at http://sip2sip.info and made possible new SIP applications that were not envisaged before like desktop sharing. The fact that commercially speaking the MSRP relay does not appeal to some SBC vendors cannot constitute a reason for deprecating a standard. I have found no technical issues with the deployment of the relay in the last 12 months of operations.=20 The fact that not many people talk about it on discussion lists does not mean that is not working or that is an irrelevant topic. The software simply works and RFC 4976 is good example of well designed IETF standard.=20 Yours sincerely, Adrian Georgescu AG Projects =09 From christer.holmberg@ericsson.com Tue Feb 24 13:58:10 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8050528C143 for ; Tue, 24 Feb 2009 13:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 sAtdme9wv1Cs for ; Tue, 24 Feb 2009 13:58:09 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4690C28C13C for ; Tue, 24 Feb 2009 13:58:09 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C99622126C; Tue, 24 Feb 2009 22:58:27 +0100 (CET) X-AuditID: c1b4fb3e-af0c1bb000001315-e0-49a46d8268c8 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8B46421263; Tue, 24 Feb 2009 22:58:26 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 22:58:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 22:58:25 +0100 Message-ID: In-Reply-To: <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs thread-index: AcmWjQc/Gf5HZo/lQM+AxD2DXeo8GQAPP8jQ References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 24 Feb 2009 21:58:26.0370 (UTC) FILETIME=[0507E220:01C996CB] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:58:10 -0000 Hi,=20 >>Maybe we should just live with the fact that it doesn=B4t work with=20 >>relays, and a receiving entity which wants to use relays should reject = >>the msrp-acm offer. As Hadriel said, an SBC operator most likely=20 >>requires all the traffic to pass the SBC, so legacy MSRP usage would=20 >>not work anyway. > >I'm not sure I agree. It seems like that takes us from "probably won't = interoperate" to "definitely won't interoperate." > >>From my experience, people asking for MSRP wants the acm solution, =20 >>because they want it to work with their SBCs, in order to anchor the =20 >>MSRP "media" (for whatever policy etc reasons). I haven't heard =20 >>about anyone asking for MSRP relays. >> >>And, since the number of deployed MSRP relays seems to be very =20 >>small, it probably wouldn't cause any major real-life problems. >> >>So, if we get this done, I think people will switch to msrp-acm. > >This quickly returns to the "if we go down this path, we have =20 >effectively deprecated MSRP relays." situation. If the community =20 >wants to do that, so be it. But I really don't want to split the =20 >standard so that we have two implementation choices that can't =20 >interoperate. The question is still whether that will be a real-life problem. How = often will it happen? Are the potential benefits bigger? But, of course, if it can work with nodes behind relays that is of = course not a bad thing. Regards, Christer > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Monday, February 23, 2009 8:14 PM > To: Hadriel Kaplan > Cc: Simple WG; Christer Holmberg > Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs > > > On Feb 23, 2009, at 11:37 AM, Hadriel Kaplan wrote: > >> >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@estacado.net] >>> Sent: Sunday, February 22, 2009 9:14 PM >>> >>> I assume your old code already handles TCP based media? >> >> Yup. Many others' do as well. >> >> >>> You are correct, RFC 4975 currently says you match the entire MSRP >>> URI to the session, which includes the address and port, or >>> conceivably a host name and port. But if we updated that to only >>> match on the Session ID (i.e. that part of the URL right of the "/", >>> it _might_ be good enough. This would allow the session match to =20 >>> work >>> even if the address:port gets changed in flight. >> >> So now we're talking about changing the endpoints and the Relays, no? >> So that doesn't jive with the idea of working with legacy RFC4975/6, >> does it? (or am I missing something?) > > It would not work with RFC4975/6 devices without a change. But then =20 > again, neither would the msrp-acm draft. > >> >> >> -hadriel > From HKaplan@acmepacket.com Tue Feb 24 14:12:50 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF613A6A11 for ; Tue, 24 Feb 2009 14:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] 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 kRB4qtSYu1-S for ; Tue, 24 Feb 2009 14:12:50 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 03DD13A69BA for ; Tue, 24 Feb 2009 14:12:50 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 24 Feb 2009 17:11:46 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Feb 2009 17:11:46 -0500 From: Hadriel Kaplan To: Ben Campbell , Christer Holmberg Date: Tue, 24 Feb 2009 17:11:44 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: AcmWjNX7iX/dYWKgQqGH4xVSzASlXQAAljNA Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> In-Reply-To: <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:12:51 -0000 > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Tuesday, February 24, 2009 9:35 AM > > This quickly returns to the "if we go down this path, we have > effectively deprecated MSRP relays." situation. If the community > wants to do that, so be it. But I really don't want to split the > standard so that we have two implementation choices that can't > interoperate. I don't think that's what we're saying. We have a session-creating rendezv= ous protocol (SIP) with address advertisement and capability negotiation (S= DP) which allows us to offer different media-layer connection schemes and a= ttributes. So we're saying let SIP and SDP do their job - let them adverti= se what each side supports. That's what they do for codecs, srtp, audio/vi= deo, etc. If the two sides each support incompatible choices, then sure it= won't work - just like it won't if we don't have common media capabilities= . -hadriel