From raveen.sharma@gmail.com Thu Jul 2 23: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 7ECCD3A6911 for ; Thu, 2 Jul 2009 23:01:07 -0700 (PDT) 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 5BTBFgenGIX8 for ; Thu, 2 Jul 2009 23:01:07 -0700 (PDT) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by core3.amsl.com (Postfix) with ESMTP id EBC833A68D6 for ; Thu, 2 Jul 2009 23:01:06 -0700 (PDT) Received: by gxk24 with SMTP id 24so3480091gxk.16 for ; Thu, 02 Jul 2009 23:01:29 -0700 (PDT) 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=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=gZRHnSEG29+AMbUfGQF/p96GCI/wwXOrV+ONfVoDUb6lYjsIEpGBnGBWMEyaBgqdVI N64n0pn/+iYFBt3vMGjgQM6aH7eqkRSzrojXRkpIpvpuuuwR0eW2tZ5/OZibRd1/unfm gK+9i10fWBqHkP0PdqJUzItP0oV+wSRsEPp/U= 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=wD8WEz6DO9wtBzx/TpVc7/T90Ik6uOQ28NI1ApyFef8wONAJs1f0DlWXdxzGW7DtiF jGnWN5kBXO+B86sk7wQE7sVmAnBY+SKNIn0BNq5JJdnqqYsyItN9RYFOaib3Td730oSk Ed7LB1z3PNhWThyNnc/RsCFdxQkZbhC50DrM8= MIME-Version: 1.0 Received: by 10.90.66.10 with SMTP id o10mr764580aga.8.1246600889758; Thu, 02 Jul 2009 23:01:29 -0700 (PDT) Date: Fri, 3 Jul 2009 11:31:29 +0530 Message-ID: <591843920907022301r15f0a4d2q78d656d849fe1edf@mail.gmail.com> From: raveen sharma To: simple@core3.amsl.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Simple] Working with MSRP Relays. 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, 03 Jul 2009 06:01:07 -0000 From raveen.sharma@gmail.com Fri Jul 3 00:24:12 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 BF8193A6813 for ; Fri, 3 Jul 2009 00:24:12 -0700 (PDT) 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_63=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 LqEqGgr+ELmX for ; Fri, 3 Jul 2009 00:24:12 -0700 (PDT) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by core3.amsl.com (Postfix) with ESMTP id E1A3A28C1DC for ; Fri, 3 Jul 2009 00:24:09 -0700 (PDT) Received: by gxk24 with SMTP id 24so3519061gxk.16 for ; Fri, 03 Jul 2009 00:24:32 -0700 (PDT) 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=MhNImuvAxxLkQz9jj+Us2R2D/5ACcQgsqA00qvxsaAw=; b=MR1T8I4HQaJgtDNi+gyF8EaANh5kbqkW+bMY3Rm9HgGxCpX9ZGN4ckOk6HX/U5uEhU jkgPIH210bcopMp8PRQ0j+FildNMzSOx5C1C5AzPPZIe1xi84cUPuU5zVw5Zm4TYHW51 XMzA+b4Nc1qrhrLsiAc0TdD+QAByNqC0S+Fk0= 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=mNVP4UOpCVeBInIYg5wk6+/5f0p/4CJCrQGG7+RrVME2YJ3CbNscGky5TjUjTnqIO2 iOjYRGu2dZisrhpCoHVGB26xMIbzEwDHX0BxrSgBCiZODBS5u++sQQ/rhOqkxnc/JdGd e8D6RC1OSA/JOR+1erq6RGm7XPSIIOqSs/8pc= MIME-Version: 1.0 Received: by 10.90.88.17 with SMTP id l17mr818760agb.24.1246605872792; Fri, 03 Jul 2009 00:24:32 -0700 (PDT) Date: Fri, 3 Jul 2009 12:54:32 +0530 Message-ID: <591843920907030024h677df4b7lbc0b3d25cd7920b1@mail.gmail.com> From: raveen sharma To: simple Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Queries on Working with MSRP Relays(RFC 4976) 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, 03 Jul 2009 07:24:12 -0000 Hello, I have some queries regarding implemtation of MSRP Clients using relays, I am referring to rfc4976 currently 1. As referred in RFC 4976, Section 3.1, MSRP Client shall authenticate with the configured/discovered list of relays. I want to know if this authentication is per MSRP session that maps to individual m-line in SIP/SDP. Lets take a case scenario, wherein I want to transfer 3 files to the same remote user. A SIP session will be initiated with 3 m-lines. My network is configured with 2 relays, R1, R2. How authentication will be = done? Approach I - MSRP Client will send AUTH request to set of relays R1, R2 for each session. 6 (3*2) AUTH requests will be sent. Approach II - MSRP Client will send AUTH requests to each relay only once for the SIP session. 2 AUTH requests will be sent. 2. Reference RFC 4976, Section 5.1,page 12: Should same authentication vector as required for MD5 (username and password) be used for authentication with MSRP Relays as in SIP signaling or It=92s a different username and password. ?? Does this auth vector is same for all relays or its unique for each relay. 3. As per schema Section 7, " algorithm =3D "algorithm=3D" ( "MD5" / token ) " Is only MD5 based algo targeted to implement or other algos like MD5v1-AKA can be targeted in future. Typically MD5v1-AKA is suggested in IMS based network where the private/public Id of ISIM and SQN is taken as an input parameter for calculating the response and user manually does not give any username and password for authenticated. 4. RFC 4976 does not give authentication procedure refreshing like the client should send AUTH request before expiry of the timer as received in 200 ok of AUTH request. Kindly let us know which specification should be referred in the case scenario. Is there any specific guide line to handle the MSRP sessions for the case scenario if failure response received in AUTH refreshing? Regards, Raveen Sharma From Martin.Thomson@andrew.com Sun Jul 5 17:40: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 DC6A53A67A6 for ; Sun, 5 Jul 2009 17:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 vK08D6yt0Sly for ; Sun, 5 Jul 2009 17:40:43 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D11C23A681F for ; Sun, 5 Jul 2009 17:40:42 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_05_20_03_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 05 Jul 2009 20:03:11 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 19:41:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 5 Jul 2009 19:41:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continuous presence Thread-Index: Acn90nHERKDSlqv4RwqjXWhuXF7TyA== From: "Thomson, Martin" To: "Simple WG" X-OriginalArrivalTime: 06 Jul 2009 00:41:06.0167 (UTC) FILETIME=[726FF870:01C9FDD2] Subject: [Simple] Continuous presence 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, 06 Jul 2009 00:40:43 -0000 SSd2ZSBzdWJtaXR0ZWQgLTAyIG9mIHRoZSBjb250aW51b3VzLXZhbHVlZCBwcmVzZW5jZSBjb25z aWRlcmF0aW9ucyBkb2N1bWVudC4NCg0KICA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdGhvbXNvbi1zaW1wbGUtY29udC1wcmVzZW5jZS12YWwtcmVxPg0KDQpQZXJoYXBzIHRoZSBt b3N0IHNpZ25pZmljYW50IGNoYW5nZSBpcyB0aGUgcmVjb2duaXRpb24gdGhhdCBhIFBBIGlzIHBy aW1hcmlseSwgaW4gdGhlIGNhc2Ugb2YgY29udGludW91cy12YWx1ZWQgZGF0YSwgYSBjYWNoZS4g IFRoZSByZXN0IGlzIGxhcmdlbHkgZWRpdG9yaWFsLg0KDQpUaGlzIGRvY3VtZW50IGRlYWxzIHdp dGggYW4gaXNzdWUgYXQgYSBzb21ld2hhdCBkaWZmZXJlbnQgbGV2ZWwgdG8gdGhlIHJlc3Qgb2Yg dGhlIHdvcmsgaW4gdGhpcyBXRy4gIEknbSBtb3N0IGludGVyZXN0ZWQgaW4gd2hldGhlciB0aGVy ZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IGluIG1ha2luZyB0aGlzIGluZm9ybWF0aW9uIGZvcm1h bC4NCg0KVGhlcmUgYXJlIGFsc28gbW9yZSBwcmFnbWF0aWMgcXVlc3Rpb25zIHRoYXQgSSdkIGxp a2UgYW5zd2VyZWQ6DQpBcmUgdGhlcmUgcHJvYmxlbXMgaGVyZSB3b3J0aCBhZGRyZXNzaW5nPyAg KFdlJ3ZlIHNlZW4gc2lwY29yZSB0YWtlIG9uIHRoZSBldmVudCByYXRlIHdvcmssIHdoaWNoIGlz IGV4Y2VsbGVudCwgYnV0IGlzIHRoZXJlIGFueXRoaW5nIGVsc2U/KQ0KDQpJZiBzbywgYXJlIHRo ZXJlIGFyZWFzIHdoZXJlIGdlbmVyaWMgc29sdXRpb25zIGFyZSBkZXNpcmFibGU/ICBPciBzaG91 bGQgd2UgaW4gR0VPUFJJViBqdXN0IGdvIG9uIHdpdGggZGVmaW5pbmcgbG9jYXRpb24tc3BlY2lm aWMgZWxlbWVudHMgZm9yIHRoaW5ncyBsaWtlIHByZXNlbmNlIGZpbHRlcnM/DQoNCi0tTWFydGlu DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBp cyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2 aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICAN CklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXpl ZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From giladg@radvision.com Mon Jul 6 01:41:21 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 51A093A6C13 for ; Mon, 6 Jul 2009 01:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=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 x8ZEG53lsXav for ; Mon, 6 Jul 2009 01:41:20 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 0D5FC28C188 for ; Mon, 6 Jul 2009 01:41:19 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n668pV9N027877 for simple@core3.amsl.com; Mon, 6 Jul 2009 11:51:31 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n668pS6Y027867; Mon, 6 Jul 2009 11:51:28 +0300 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" Date: Mon, 6 Jul 2009 11:39:56 +0300 Message-ID: <7E27141E2F9038419E1FA26127E67EC4DB947D@rvil-mail1.RADVISION.com> In-Reply-To: <591843920907030024h677df4b7lbc0b3d25cd7920b1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Queries on Working with MSRP Relays(RFC 4976) thread-index: Acn7r2VpzulzT/WNT96g7poMuCkuMgCXs2sg References: <591843920907030024h677df4b7lbc0b3d25cd7920b1@mail.gmail.com> From: "Gilad Govrin" To: "raveen sharma" , "simple" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id n668pS6Y027867 Subject: Re: [Simple] Queries on Working with MSRP Relays(RFC 4976) 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, 06 Jul 2009 08:41:21 -0000 Hi Raveen, We are also in the stage of implementing msrp client authenticating with their Relays. 1. As far as I understand, each MSRP session should authenticate itself with its route of Relays, since, upon Authentication success the relay will send a unique session created for the authenticating session (indicated in the use-path header). So I think approach 1 is the answer. 2. Again as far as I understand it, I don't think so. Each relay manages its own user/pass database. 3. This rfc referring only MD5, there probably will be extensions rfc's/draft that will define the way to do it using AKA for example. 4. Also wondering on this one. Regards, Gilad -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of raveen sharma Sent: Friday, July 03, 2009 10:25 AM To: simple Subject: [Simple] Queries on Working with MSRP Relays(RFC 4976) Hello, I have some queries regarding implemtation of MSRP Clients using relays, I am referring to rfc4976 currently 1. As referred in RFC 4976, Section 3.1, MSRP Client shall authenticate with the configured/discovered list of relays. I want to know if this authentication is per MSRP session that maps to individual m-line in SIP/SDP. Lets take a case scenario, wherein I want to transfer 3 files to the same remote user. A SIP session will be initiated with 3 m-lines. My network is configured with 2 relays, R1, R2. How authentication will be done? Approach I - MSRP Client will send AUTH request to set of relays R1, R2 for each session. 6 (3*2) AUTH requests will be sent. Approach II - MSRP Client will send AUTH requests to each relay only once for the SIP session. 2 AUTH requests will be sent. 2. Reference RFC 4976, Section 5.1,page 12: Should same authentication vector as required for MD5 (username and password) be used for authentication with MSRP Relays as in SIP signaling or It's a different username and password. ?? Does this auth vector is same for all relays or its unique for each relay. 3. As per schema Section 7, " algorithm = "algorithm=" ( "MD5" / token ) " Is only MD5 based algo targeted to implement or other algos like MD5v1-AKA can be targeted in future. Typically MD5v1-AKA is suggested in IMS based network where the private/public Id of ISIM and SQN is taken as an input parameter for calculating the response and user manually does not give any username and password for authenticated. 4. RFC 4976 does not give authentication procedure refreshing like the client should send AUTH request before expiry of the timer as received in 200 ok of AUTH request. Kindly let us know which specification should be referred in the case scenario. Is there any specific guide line to handle the MSRP sessions for the case scenario if failure response received in AUTH refreshing? Regards, Raveen Sharma _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From AVSHALOM@il.ibm.com Wed Jul 8 08:31:32 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 E30E73A6B37 for ; Wed, 8 Jul 2009 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OdM722nsfmsR for ; Wed, 8 Jul 2009 08:31:27 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by core3.amsl.com (Postfix) with ESMTP id 7B2A628C125 for ; Wed, 8 Jul 2009 08:31:12 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n68FVJU5101312 for ; Wed, 8 Jul 2009 15:31:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n68FVFHI2380022 for ; Wed, 8 Jul 2009 17:31:18 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n68FVFlA030305 for ; Wed, 8 Jul 2009 17:31:15 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n68FVFEm030302 for ; Wed, 8 Jul 2009 17:31:15 +0200 To: simple@ietf.org MIME-Version: 1.0 X-KeepSent: 28D9AF4E:34107FED-C22575ED:00503498; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Wed, 8 Jul 2009 18:31:14 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 08/07/2009 18:31:14, Serialize complete at 08/07/2009 18:31:14 Content-Type: multipart/alternative; boundary="=_alternative 00553CC8C22575ED_=" Subject: [Simple] Planned changes for draft-ietf-simple-interdomain-scaling analysis-06 after the LC 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, 08 Jul 2009 15:31:33 -0000 This is a multipart message in MIME format. --=_alternative 00553CC8C22575ED_= Content-Type: text/plain; charset="US-ASCII" The following are the planned changes to the document after the IETF last call. * Definition of a day in the document is not clear (Joel M. Helpern) -- For the definition of a day, I will add in the definition of C01 that 8 hours lifetime of subscriptions that is defined in C01 and a day are synonymous in this document. * Many typos and English usages will be fixed. Many thanks to Jean Mahoney for her great help here. The reference to draft-niemi-sipping-event-throttle will be changed to draft-ietf-sipcore-event-rate-control. Thanks --Avshalom --=_alternative 00553CC8C22575ED_= Content-Type: text/html; charset="US-ASCII" The following are the planned changes to the document after the IETF last call.

* Definition of a day in the document is not clear (Joel M. Helpern)

-- For the definition of a day, I will add in the definition of C01 that 8 hours lifetime of subscriptions that is defined in C01 and a day are synonymous in this document.

* Many typos and English usages will be fixed. Many thanks to Jean Mahoney for her great help here.

The reference to draft-niemi-sipping-event-throttle will be changed to draft-ietf-sipcore-event-rate-control.

Thanks
--Avshalom
 --=_alternative 00553CC8C22575ED_=-- From wwwrun@core3.amsl.com Wed Jul 8 09:29:08 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BC9EF3A6ED9; Wed, 8 Jul 2009 09:29:08 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090708162908.BC9EF3A6ED9@core3.amsl.com> Date: Wed, 8 Jul 2009 09:29:08 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-xcap-diff (An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources) to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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, 08 Jul 2009 16:29:08 -0000 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-13.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12965&rfc_flag=0 From root@core3.amsl.com Wed Jul 8 15:00:01 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D35113A6FA6; Wed, 8 Jul 2009 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090708220001.D35113A6FA6@core3.amsl.com> Date: Wed, 8 Jul 2009 15:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-interdomain-scaling-analysis-07.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: Wed, 08 Jul 2009 22:00:01 -0000 --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 : Presence Interdomain Scaling Analysis for SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-simple-interdomain-scaling-analysis-07.txt Pages : 61 Date : 2009-07-08 The document analyzes the traffic that is generated by presence subscriptions between domains and shows that the amount of traffic can be extremely large. The document also analyzes the effects of a large presence system on the memory footprint and the CPU load. Approved and in-work optimizations to the Session Initiation Protocol are analyzed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.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-interdomain-scaling-analysis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-08144719.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Thu Jul 9 15:07:08 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 31B213A6A5A; Thu, 9 Jul 2009 15:07:08 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090709220708.31B213A6A5A@core3.amsl.com> Date: Thu, 9 Jul 2009 15:07:08 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-interdomain-scaling-analysis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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, 09 Jul 2009 22:07:08 -0000 (Presence Interdomain Scaling Analysis for SIP/SIMPLE) to Informational RFC The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Interdomain Scaling Analysis for SIP/SIMPLE ' as an Informational RFC This is a 2nd last call on this document. Comments from the IETF Last Call on version -06 of this document led to editorial changes throughout the document. A few clarifications were added, but no technical content should have changed. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15780&rfc_flag=0 From wwwrun@core3.amsl.com Thu Jul 9 16:59:26 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0CEE33A6A5C; Thu, 9 Jul 2009 16:59:25 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090709235926.0CEE33A6A5C@core3.amsl.com> Date: Thu, 9 Jul 2009 16:59:26 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-interdomain-scaling-analysis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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, 09 Jul 2009 23:59:26 -0000 (Presence Interdomain Scaling Analysis for SIP/SIMPLE) to Informational RFC The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Interdomain Scaling Analysis for SIP/SIMPLE ' as an Informational RFC This is a 2nd last call on this document. Comments from the IETF Last Call on version -06 of this document led to editorial changes throughout the document. A few clarifications were added, but no technical content should have changed. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15780&rfc_flag=0 From wwwrun@core3.amsl.com Thu Jul 9 17:07:21 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1DEA83A6D2F; Thu, 9 Jul 2009 17:07:21 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090710000721.1DEA83A6D2F@core3.amsl.com> Date: Thu, 9 Jul 2009 17:07:21 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-interdomain-scaling-analysis (Presence Interdomain Scaling Analysis for SIP/SIMPLE) to Informational RFC X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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, 10 Jul 2009 00:07:21 -0000 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Presence Interdomain Scaling Analysis for SIP/SIMPLE ' as an Informational RFC This is a 2nd last call on this document. Comments from the IETF Last Call on version -06 of this document led to editorial changes throughout the document. A few clarifications were added, but no technical content should have changed. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15780&rfc_flag=0 From AVSHALOM@il.ibm.com Sat Jul 11 13:03:30 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 BD80E3A6B12 for ; Sat, 11 Jul 2009 13:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 52XGVA6y-q+X for ; Sat, 11 Jul 2009 13:03:29 -0700 (PDT) Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by core3.amsl.com (Postfix) with ESMTP id 9ADBA3A6ADD for ; Sat, 11 Jul 2009 13:03:29 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.14.3/8.13.8) with ESMTP id n6BK3gBI111682 for ; Sat, 11 Jul 2009 20:03:42 GMT Received: from d12av06.megacenter.de.ibm.com (d12av06.megacenter.de.ibm.com [9.149.165.230]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6BK3Zw52662460 for ; Sat, 11 Jul 2009 22:03:41 +0200 Received: from d12av06.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av06.megacenter.de.ibm.com (8.13.1/8.13.3) with ESMTP id n6BK3Z4u021439 for ; Sat, 11 Jul 2009 22:03:35 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av06.megacenter.de.ibm.com (8.13.1/8.12.11) with ESMTP id n6BK3Zis021436 for ; Sat, 11 Jul 2009 22:03:35 +0200 To: simple@ietf.org MIME-Version: 1.0 X-KeepSent: 8DC19993:9A3BC73C-C22575F0:006CE0B8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Sat, 11 Jul 2009 23:03:32 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 11/07/2009 23:03:34, Serialize complete at 11/07/2009 23:03:34 Content-Type: multipart/alternative; boundary="=_alternative 006E2BE0C22575F0_=" Subject: [Simple] Next changes in draf-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: Sat, 11 Jul 2009 20:03:30 -0000 This is a multipart message in MIME format. --=_alternative 006E2BE0C22575F0_= Content-Type: text/plain; charset="US-ASCII" Two issues were raised in the San Francisco meeting regarding draft-ietf-simple- intradomain-federation Issue A - PUBLISH ----------------- The document assumes that servers will subscribe to each other. It is also possible that when configuration is known a server will publish presence information to another server. Suggested change: A comment will be added saying that since we deal with presence servers we prefer to assume subscription but publish can also be used (if who should report to whom is known). Issue B - Policy ---------------- There were two concerns that were raised in the meeting: Policy - Concern 1: Policy may be inconsistent and would depend on the server that I am subscribing to. Adam and Ben have raised the issue that the user can not know for sure what other users will see and it is a security concern. Policy - Concern 2: Policy as it is described currently in the draft is not compatible with common-policy. The draft assumes "and" policy while common- policy allows for other models. Suggested change is to add text to the draft based on the following: It seems that a real life solution will be based on a centralized policy model where there may be different interfaces to the centralized repository and decision making to allow for different protocol/usages. Any attempt to assume that users will be able to configure and understand what will happen in a distributed policy seems to be futile. So it seems that the centralized policy is the right approach but if there is a need to use distributed policy, the concerns that were raised should be considered. Comments? --Avshalom --=_alternative 006E2BE0C22575F0_= Content-Type: text/html; charset="US-ASCII" Two issues were raised in the San Francisco meeting regarding draft-ietf-simple-
intradomain-federation

Issue A - PUBLISH
-----------------

The document assumes that servers will subscribe to each other. It is also
possible that when configuration is known a server will publish presence
information to another server.

Suggested change:

A comment will be added saying that since we deal with presence servers we
prefer to assume subscription but publish can also be used (if who should report
to whom is known).

Issue B - Policy
----------------

There were two concerns that were raised in the meeting:

Policy - Concern 1: Policy may be inconsistent and would depend on the server
that I am subscribing to. Adam and Ben have raised the issue that the user can
not know for sure what other users will see and it is a security concern.

Policy - Concern 2: Policy as it is described currently in the draft  is not
compatible with common-policy. The draft assumes "and" policy while common-
policy allows for other models.

Suggested change is to add text to the draft based on the following:

It seems that a real life solution will be based on a centralized policy model
where there may be different interfaces to the centralized repository and
decision making to allow for different protocol/usages.
 
Any attempt to assume that users will be able to configure and understand what
will happen in a distributed policy seems to be futile.

So it seems that the centralized policy is the right approach but if there is a
need to use distributed policy, the concerns that were raised should be
considered.

Comments?

--Avshalom
--=_alternative 006E2BE0C22575F0_=-- From ben@estacado.net Mon Jul 13 08:54: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 25BC53A6D28 for ; Mon, 13 Jul 2009 08:54:16 -0700 (PDT) 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 q9r3nUgfX9l9 for ; Mon, 13 Jul 2009 08:54:15 -0700 (PDT) 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 37E7228C2DB for ; Mon, 13 Jul 2009 08:53:54 -0700 (PDT) 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 n6DFsJEM015138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2009 10:54:19 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <11247AA0-3CEA-4F68-B647-989F43A9C4F1@estacado.net> From: Ben Campbell To: Simple WG In-Reply-To: <11BE4F4A-F2CD-4C76-A6F2-A83B57801130@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 10:54:19 -0500 References: <11BE4F4A-F2CD-4C76-A6F2-A83B57801130@nostrum.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Simple] SIMPLE Agenda Requests for IETF75 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, 13 Jul 2009 15:54:16 -0000 Last call on agenda requests. If you need agenda time and have not already sent a request to the SIMPLE chairs, please do so by July 15. On Jun 29, 2009, at 10:49 AM, Ben Campbell wrote: > We currently have an agenda request from Christer (msrp-acm draft). > Is there anything else we need to discuss in Stockholm? > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From root@core3.amsl.com Mon Jul 13 09:45:02 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3735728C4BD; Mon, 13 Jul 2009 09:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713164502.3735728C4BD@core3.amsl.com> Date: Mon, 13 Jul 2009 09:45:02 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-intradomain-federation-04.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: Mon, 13 Jul 2009 16:45:02 -0000 --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 : Models for Intra-Domain Presence and Instant Messaging (IM) Bridging Author(s) : J. Rosenberg, et al. Filename : draft-ietf-simple-intradomain-federation-04.txt Pages : 48 Date : 2009-07-13 Presence and Instant Messaging (IM) bridging involves the sharing of presence information and exchange of IM across multiple systems within a single domain. As such, it is a close cousin to presence and IM federation, which involves the sharing of presence and IM across differing domains. Presence and IM bridging can be the result of a multi-vendor network, or a consequence of a large organization that requires partitioning. This document examines different use cases and models for intra-domain presence and IM bridging. It is meant to provide a framework for defining requirements and specifications for presence and IM bridging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-intradomain-federation-04.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-intradomain-federation-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13094439.I-D@ietf.org> --NextPart-- From AVSHALOM@il.ibm.com Mon Jul 13 09:51: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 9959628C4F2 for ; Mon, 13 Jul 2009 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Xp1LZLy9fpHf for ; Mon, 13 Jul 2009 09:51:42 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id 1F10B28C519 for ; Mon, 13 Jul 2009 09:50:35 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n6DGp2xl017875 for ; Mon, 13 Jul 2009 16:51:02 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6DGp2gP2740422 for ; Mon, 13 Jul 2009 18:51:02 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6DGp22O018835 for ; Mon, 13 Jul 2009 18:51:02 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6DGp2eU018830 for ; Mon, 13 Jul 2009 18:51:02 +0200 To: simple@ietf.org MIME-Version: 1.0 X-KeepSent: 649B0698:6F89FB4D-C22575F2:005C47BF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Mon, 13 Jul 2009 19:50:55 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 13/07/2009 19:51:02, Serialize complete at 13/07/2009 19:51:02 Content-Type: multipart/alternative; boundary="=_alternative 005C578EC22575F2_=" Subject: [Simple] Next changes in draf-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: Mon, 13 Jul 2009 16:51:43 -0000 This is a multipart message in MIME format. --=_alternative 005C578EC22575F2_= Content-Type: text/plain; charset="US-ASCII" New version that reflects the changes below has been submitted. http://tools.ietf.org/html/draft-ietf-simple-intradomain-federation-04 Thanks --Avshalom __________________ Two issues were raised in the San Francisco meeting regarding draft-ietf-simple- intradomain-federation Issue A - PUBLISH ----------------- The document assumes that servers will subscribe to each other. It is also possible that when configuration is known a server will publish presence information to another server. Suggested change: A comment will be added saying that since we deal with presence servers we prefer to assume subscription but publish can also be used (if who should report to whom is known). Issue B - Policy ---------------- There were two concerns that were raised in the meeting: Policy - Concern 1: Policy may be inconsistent and would depend on the server that I am subscribing to. Adam and Ben have raised the issue that the user can not know for sure what other users will see and it is a security concern. Policy - Concern 2: Policy as it is described currently in the draft is not compatible with common-policy. The draft assumes "and" policy while common- policy allows for other models. Suggested change is to add text to the draft based on the following: It seems that a real life solution will be based on a centralized policy model where there may be different interfaces to the centralized repository and decision making to allow for different protocol/usages. Any attempt to assume that users will be able to configure and understand what will happen in a distributed policy seems to be futile. So it seems that the centralized policy is the right approach but if there is a need to use distributed policy, the concerns that were raised should be considered. Comments? --Avshalom --=_alternative 005C578EC22575F2_= Content-Type: text/html; charset="US-ASCII" New version that reflects the changes below has been submitted.

http://tools.ietf.org/html/draft-ietf-simple-intradomain-federation-04
Thanks
--Avshalom
__________________

Two issues were raised in the San Francisco meeting regarding draft-ietf-simple-
intradomain-federation

Issue A - PUBLISH
-----------------

The document assumes that servers will subscribe to each other. It is also
possible that when configuration is known a server will publish presence
information to another server.

Suggested change:

A comment will be added saying that since we deal with presence servers we
prefer to assume subscription but publish can also be used (if who should report
to whom is known).

Issue B - Policy
----------------

There were two concerns that were raised in the meeting:

Policy - Concern 1: Policy may be inconsistent and would depend on the server
that I am subscribing to. Adam and Ben have raised the issue that the user can
not know for sure what other users will see and it is a security concern.

Policy - Concern 2: Policy as it is described currently in the draft  is not
compatible with common-policy. The draft assumes "and" policy while common-
policy allows for other models.

Suggested change is to add text to the draft based on the following:

It seems that a real life solution will be based on a centralized policy model
where there may be different interfaces to the centralized repository and
decision making to allow for different protocol/usages.
 
Any attempt to assume that users will be able to configure and understand what
will happen in a distributed policy seems to be futile.

So it seems that the centralized policy is the right approach but if there is a
need to use distributed policy, the concerns that were raised should be
considered.

Comments?

--Avshalom
--=_alternative 005C578EC22575F2_=-- From ben@nostrum.com Wed Jul 15 13:54:45 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 035FB3A68D2 for ; Wed, 15 Jul 2009 13:54:45 -0700 (PDT) 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=[AWL=0.000, 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 AE0oWjz7K-OS for ; Wed, 15 Jul 2009 13:54:44 -0700 (PDT) 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 AE3C53A6B30 for ; Wed, 15 Jul 2009 13:54:40 -0700 (PDT) Received: from dn3-109.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6FKt6i4065069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 15:55:07 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <47F88BB7-E0F6-4087-96C7-D5D582E4501D@nostrum.com> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 15:55:06 -0500 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] Draft Agenda: SIMPLE@IETF75 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, 15 Jul 2009 20:54:45 -0000 Please send comments/change requests quickly: SIMPLE: Wednesday July 29 : 1510-1610 (Afternoon Session II) 10m - Administrivia 10m - Intradomain - Avshalom draft-ietf-simple-intradomain-federation-04.txt 40m - MSRP-ACM - Christer draft-ietf-simple-msrp-acm-00.txt From ben@nostrum.com Mon Jul 20 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 312AF3A6802 for ; Mon, 20 Jul 2009 14:12:50 -0700 (PDT) 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 Mvk3yzv5VIwq for ; Mon, 20 Jul 2009 14:12:41 -0700 (PDT) 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 16F773A67D7 for ; Mon, 20 Jul 2009 14:12:40 -0700 (PDT) Received: from dn3-109.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6KLCWSR064745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Jul 2009 16:12:35 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 16:12:32 -0500 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] COMEDIA vs MSRP Relays: Which Connection? 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, 20 Jul 2009 21:12:50 -0000 (As individual) We've had quite a bit of discussion about how the Transport Connection Addressing Section (draft-ietf-simple-msrp-acm-00 section 4.2) may or may not work with MSRP relays. I'd like to make sure we're not neglecting how the COMEDIA Usage section (Section 4.1 and children) interact with MSRP relays. I think there are some open questions. Since each one seems likely to generate a thread of discussion, I'm sending them separately: When MSRP relays are present, there will be two or more TCP connections involved in a particular session. Which connection is being negotiated via COMEDIA? I _think_ the answer is the connection between boundary relays--that is, between the outermost relay of party A and the outermost relay of party B. If one party uses a chain of relays, only the outer one would require COMEDIA negotiation. I guess you could also look at this as the connection that crosses domains, for some vague definition of domain. There might be an interesting case here for when both parties share the same relay. From ben@nostrum.com Mon Jul 20 14:14: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 C2BDE3A6AF8 for ; Mon, 20 Jul 2009 14:14:43 -0700 (PDT) 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 7UFnKZDSzkVy for ; Mon, 20 Jul 2009 14:14:34 -0700 (PDT) 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 A1C8F3A6B9F for ; Mon, 20 Jul 2009 14:14:33 -0700 (PDT) Received: from dn3-109.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6KLETIx064871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Jul 2009 16:14:30 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 16:14:29 -0500 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 20 Jul 2009 21:14:43 -0000 (As individual) We've had quite a bit of discussion about how the Transport Connection Addressing Section (draft-ietf-simple-msrp-acm-00 section 4.2) may or may not work with MSRP relays. I'd like to make sure we're not neglecting how the COMEDIA Usage section (Section 4.1 and children) interact with MSRP relays. I think there are some open questions. Since each one seems likely to generate a thread of discussion, I'm sending them separately: How does the COMEDIA negotiation interact with the TCP-connection- sharing features of MSRP? We negotiate sessions in the SDP offer/ answer, not connections per se. COMEDIA implicitly assumes a one-to- one correspondence between these, but MSRP explicitly allows multiple sessions to use the same TCP connection. I can see two approaches. One would be that the COMEDIA attributes are only relevant if you have to create a new connection. If a reusable connection already exists, you just use it. Alternatively, we could state that a connection is only reuseable if it's direction matches the COMEDIA attributes, and if devices wanted to reuse an existing connection, they would either omit COMEDIA entirely, or choose COMEDIA attributes that match the connection. Neither of those approaches seems obviously wrong to me. I suspect there may be some traps here, though--we should analyze this pretty closely. From ben@nostrum.com Mon Jul 20 14:16: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 81CA33A6BC5 for ; Mon, 20 Jul 2009 14:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 ElVlIBndZ2Y1 for ; Mon, 20 Jul 2009 14:16:37 -0700 (PDT) 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 677A53A6DD0 for ; Mon, 20 Jul 2009 14:16:37 -0700 (PDT) Received: from dn3-109.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6KLGYkb065051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Jul 2009 16:16:35 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 16:16:34 -0500 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] COMEDIA vs MSRP Relays: COMEDIA-TLS 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, 20 Jul 2009 21:16:38 -0000 (As individual) We've had quite a bit of discussion about how the Transport Connection Addressing Section (draft-ietf-simple-msrp-acm-00 section 4.2) may or may not work with MSRP relays. I'd like to make sure we're not neglecting how the COMEDIA Usage section (Section 4.1 and children) interact with MSRP relays. I think there are some open questions. Since each one seems likely to generate a thread of discussion, I'm sending them separately: How does COMEDIA-TLS work with MSRP relays? (There has been some discussion on this one, but I don't recall any conclusions) If I understand correctly, RFC 4572 is really only designed for the use of self-signed TLS certs. At least, it states parties to a TLS session MUST provide certificate fingerprints. This is an issue for MSRP relays, as relays are not involved in the SDP offer/answer, and the endpoints are not going to necessarily know the fingerprints of certificates used by a relay. Also, it's quite likely that an MSRP relay will use a cert signed by a well-known CA, where a fingerprint would not add much value. From HKaplan@acmepacket.com Tue Jul 21 15:10:30 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 5C8C63A6EBD for ; Tue, 21 Jul 2009 15:10:30 -0700 (PDT) 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 3nNf-AjMXjuU for ; Tue, 21 Jul 2009 15:10:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8F4033A6EBE for ; Tue, 21 Jul 2009 15:10:25 -0700 (PDT) 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.375.2; Tue, 21 Jul 2009 18:10:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 21 Jul 2009 18:10:24 -0400 From: Hadriel Kaplan To: Ben Campbell , Simple WG Date: Tue, 21 Jul 2009 18:10:23 -0400 Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Which Connection? Thread-Index: AcoJftiTvmDAc0SnQ96mDAtwBn+W5gA0KEyQ 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] COMEDIA vs MSRP Relays: Which Connection? 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, 21 Jul 2009 22:10:30 -0000 I assumed the same: that it's the connection to/from the (last) relay from = each side's perspective, facing to the public internet. As if the Relay we= re a TURN server, I guess. In other words, what would have been the first = MSRP URI in the use-path list in SDP. -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Monday, July 20, 2009 5:13 PM >=20 > When MSRP relays are present, there will be two or more TCP > connections involved in a particular session. Which connection is > being negotiated via COMEDIA? >=20 > I _think_ the answer is the connection between boundary relays--that > is, between the outermost relay of party A and the outermost relay of > party B. If one party uses a chain of relays, only the outer one would > require COMEDIA negotiation. I guess you could also look at this as > the connection that crosses domains, for some vague definition of > domain. >=20 > There might be an interesting case here for when both parties share > the same relay. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Tue Jul 21 15:14: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 72A303A6B7B for ; Tue, 21 Jul 2009 15:14:51 -0700 (PDT) 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 GizOzLg3Bhq6 for ; Tue, 21 Jul 2009 15:14:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 987013A683A for ; Tue, 21 Jul 2009 15:14:50 -0700 (PDT) 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.375.2; Tue, 21 Jul 2009 18:14:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 21 Jul 2009 18:14:47 -0400 From: Hadriel Kaplan To: Ben Campbell , Simple WG Date: Tue, 21 Jul 2009 18:14:42 -0400 Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoJfyRgoUhPBj6cQquBeSePZEdUnQA0Pt1A Message-ID: References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> In-Reply-To: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> 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] COMEDIA vs MSRP Relays: Shared Connections 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, 21 Jul 2009 22:14:51 -0000 I'm not sure I follow you - Comedia has a "connection:existing" attribute s= etting to re-use the same connection (e.g., in a new offer). Or do you mea= n of two separate media m=3D lines? -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell >=20 > How does the COMEDIA negotiation interact with the TCP-connection- > sharing features of MSRP? We negotiate sessions in the SDP offer/ > answer, not connections per se. COMEDIA implicitly assumes a one-to- > one correspondence between these, but MSRP explicitly allows multiple > sessions to use the same TCP connection. >=20 > I can see two approaches. One would be that the COMEDIA attributes are > only relevant if you have to create a new connection. If a reusable > connection already exists, you just use it. Alternatively, we could > state that a connection is only reuseable if it's direction matches > the COMEDIA attributes, and if devices wanted to reuse an existing > connection, they would either omit COMEDIA entirely, or choose COMEDIA > attributes that match the connection. >=20 > Neither of those approaches seems obviously wrong to me. I suspect > there may be some traps here, though--we should analyze this pretty > closely. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Tue Jul 21 15:17: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 3FE4D3A6B7B for ; Tue, 21 Jul 2009 15:17:44 -0700 (PDT) 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 Ao-3RoX5tRjn for ; Tue, 21 Jul 2009 15:17:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5A42F3A6AC0 for ; Tue, 21 Jul 2009 15:17:43 -0700 (PDT) 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.375.2; Tue, 21 Jul 2009 18:17:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 21 Jul 2009 18:17:39 -0400 From: Hadriel Kaplan To: Ben Campbell , Simple WG Date: Tue, 21 Jul 2009 18:17:34 -0400 Thread-Topic: [Simple] COMEDIA vs MSRP Relays: COMEDIA-TLS Thread-Index: AcoJf2trBPtYFbNxTxCwcIjEhAXGVAA0Tx2g 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] COMEDIA vs MSRP Relays: COMEDIA-TLS 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, 21 Jul 2009 22:17:44 -0000 Yup, I noted that issue in one of the earlier emails (long ago): that if we= use the fingerprint with MSRP Relays, then we need a way for a UA to learn= the fingerprint of its Relay(s). (presumably through the MSRP messaging it= uses to get the use-path MSRP URI from such Relay(s)?) -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > > How does COMEDIA-TLS work with MSRP relays? (There has been some > discussion on this one, but I don't recall any conclusions) >=20 > If I understand correctly, RFC 4572 is really only designed for the > use of self-signed TLS certs. At least, it states parties to a TLS > session MUST provide certificate fingerprints. This is an issue for > MSRP relays, as relays are not involved in the SDP offer/answer, and > the endpoints are not going to necessarily know the fingerprints of > certificates used by a relay. Also, it's quite likely that an MSRP > relay will use a cert signed by a well-known CA, where a fingerprint > would not add much value. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Jul 21 15:31: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 F1AF43A6B7B for ; Tue, 21 Jul 2009 15:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 xC22hcxHpgvC for ; Tue, 21 Jul 2009 15:31:25 -0700 (PDT) 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 C02F83A694C for ; Tue, 21 Jul 2009 15:31:24 -0700 (PDT) Received: from dn3-213.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6LMVLB2081352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2009 17:31:21 -0500 (CDT) (envelope-from ben@nostrum.com) 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 v935.3) Date: Tue, 21 Jul 2009 17:31:21 -0500 References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 21 Jul 2009 22:31:26 -0000 On Jul 21, 2009, at 5:14 PM, Hadriel Kaplan wrote: > > I'm not sure I follow you - Comedia has a "connection:existing" > attribute setting to re-use the same connection (e.g., in a new > offer). Or do you mean of two separate media m= lines? You are right of course. Brain fart on my part. However, the draft should probably mention how to apply this--the only reference I see to connection:existing is in the ICE section. > > -hadriel > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Ben Campbell >> >> How does the COMEDIA negotiation interact with the TCP-connection- >> sharing features of MSRP? We negotiate sessions in the SDP offer/ >> answer, not connections per se. COMEDIA implicitly assumes a one-to- >> one correspondence between these, but MSRP explicitly allows multiple >> sessions to use the same TCP connection. >> >> I can see two approaches. One would be that the COMEDIA attributes >> are >> only relevant if you have to create a new connection. If a reusable >> connection already exists, you just use it. Alternatively, we could >> state that a connection is only reuseable if it's direction matches >> the COMEDIA attributes, and if devices wanted to reuse an existing >> connection, they would either omit COMEDIA entirely, or choose >> COMEDIA >> attributes that match the connection. >> >> Neither of those approaches seems obviously wrong to me. I suspect >> there may be some traps here, though--we should analyze this pretty >> closely. >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Jul 21 16:04: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 B486F3A6967 for ; Tue, 21 Jul 2009 16:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 g07IMeYxESX6 for ; Tue, 21 Jul 2009 16:04:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 512A03A6EC3 for ; Tue, 21 Jul 2009 16:04:11 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-53-4a66496a4e48 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1D.D2.00514.A69466A4; Wed, 22 Jul 2009 01:04:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 01:03:27 +0200 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: Wed, 22 Jul 2009 01:02:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoKUv3sO58GPAV9SGGZwJDcfX8IegABE+WY References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" , "Hadriel Kaplan" X-OriginalArrivalTime: 21 Jul 2009 23:03:27.0547 (UTC) FILETIME=[750980B0:01CA0A57] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 21 Jul 2009 23:04:28 -0000 Hi, =20 Section 4.1.3 talks about the connection attribute. =20 Regards, =20 Christer =20 ________________________________ From: simple-bounces@ietf.org on behalf of Ben Campbell Sent: Wed 22/07/2009 00:31 To: Hadriel Kaplan Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections On Jul 21, 2009, at 5:14 PM, Hadriel Kaplan wrote: > > I'm not sure I follow you - Comedia has a "connection:existing"=20 > attribute setting to re-use the same connection (e.g., in a new=20 > offer). Or do you mean of two separate media m=3D lines? You are right of course. Brain fart on my part. However, the draft=20 should probably mention how to apply this--the only reference I see to=20 connection:existing is in the ICE section. > > -hadriel > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >> Behalf >> Of Ben Campbell >> >> How does the COMEDIA negotiation interact with the TCP-connection- >> sharing features of MSRP? We negotiate sessions in the SDP offer/ >> answer, not connections per se. COMEDIA implicitly assumes a one-to- >> one correspondence between these, but MSRP explicitly allows multiple >> sessions to use the same TCP connection. >> >> I can see two approaches. One would be that the COMEDIA attributes=20 >> are >> only relevant if you have to create a new connection. If a reusable >> connection already exists, you just use it. Alternatively, we could >> state that a connection is only reuseable if it's direction matches >> the COMEDIA attributes, and if devices wanted to reuse an existing >> connection, they would either omit COMEDIA entirely, or choose=20 >> COMEDIA >> attributes that match the connection. >> >> Neither of those approaches seems obviously wrong to me. I suspect >> there may be some traps here, though--we should analyze this pretty >> closely. >> >> _______________________________________________ >> 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 christer.holmberg@ericsson.com Tue Jul 21 16:05:34 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 BEA523A6E7F for ; Tue, 21 Jul 2009 16:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 A6oNUKdptcvX for ; Tue, 21 Jul 2009 16:05:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7EE103A63CB for ; Tue, 21 Jul 2009 16:05:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-8d-4a6649b342c6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 10.E2.00514.3B9466A4; Wed, 22 Jul 2009 01:05:24 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 01:05:17 +0200 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: Wed, 22 Jul 2009 01:03:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: COMEDIA-TLS Thread-Index: AcoJf2trBPtYFbNxTxCwcIjEhAXGVAA0Tx2gAAG2lM8= References: From: "Christer Holmberg" To: "Hadriel Kaplan" , "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 21 Jul 2009 23:05:17.0101 (UTC) FILETIME=[B6561DD0:01CA0A57] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] COMEDIA vs MSRP Relays: COMEDIA-TLS 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, 21 Jul 2009 23:05:34 -0000 Hi, =20 This is listed as an open issue in my presentation.=20 =20 The currently available solution proposal is to send the information in = the MSRP message itself. =20 Regards, =20 Christer ________________________________ From: simple-bounces@ietf.org on behalf of Hadriel Kaplan Sent: Wed 22/07/2009 00:17 To: Ben Campbell; Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: COMEDIA-TLS Yup, I noted that issue in one of the earlier emails (long ago): that if = we use the fingerprint with MSRP Relays, then we need a way for a UA to = learn the fingerprint of its Relay(s). (presumably through the MSRP = messaging it uses to get the use-path MSRP URI from such Relay(s)?) -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf > Of Ben Campbell > > How does COMEDIA-TLS work with MSRP relays? (There has been some > discussion on this one, but I don't recall any conclusions) > > If I understand correctly, RFC 4572 is really only designed for the > use of self-signed TLS certs. At least, it states parties to a TLS > session MUST provide certificate fingerprints. This is an issue for > MSRP relays, as relays are not involved in the SDP offer/answer, and > the endpoints are not going to necessarily know the fingerprints of > certificates used by a relay. Also, it's quite likely that an MSRP > relay will use a cert signed by a well-known CA, where a fingerprint > would not add much value. > > _______________________________________________ > 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 christer.holmberg@ericsson.com Tue Jul 21 16:10:26 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 CAE523A6EB5 for ; Tue, 21 Jul 2009 16:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 0pcvbbl2KeUP for ; Tue, 21 Jul 2009 16:10:26 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 904623A688F for ; Tue, 21 Jul 2009 16:10:25 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-ef-4a664ae06894 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 03.F6.18827.0EA466A4; Wed, 22 Jul 2009 01:10:24 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 01:10:03 +0200 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: Wed, 22 Jul 2009 01:06:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Which Connection? Thread-Index: AcoJftiTvmDAc0SnQ96mDAtwBn+W5gA0KEyQAAIaXKw= References: From: "Christer Holmberg" To: "Hadriel Kaplan" , "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 21 Jul 2009 23:10:03.0146 (UTC) FILETIME=[60D51EA0:01CA0A58] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] COMEDIA vs MSRP Relays: Which Connection? 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, 21 Jul 2009 23:10:26 -0000 Hi, =20 This is listed as an open issue in my presentation. =20 It is related to an issue raised by Ben a while ago, that comedia also = decides which party sends the first MSRP message.=20 =20 So, combining the solution proposals for both issues: if a client behind = a relay is "passive", it would still establish an TCP connection with = its relay, but it would not send the first MSRP SEND.=20 =20 Regards, =20 Christer ________________________________ From: simple-bounces@ietf.org on behalf of Hadriel Kaplan Sent: Wed 22/07/2009 00:10 To: Ben Campbell; Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Which Connection? I assumed the same: that it's the connection to/from the (last) relay = from each side's perspective, facing to the public internet. As if the = Relay were a TURN server, I guess. In other words, what would have been = the first MSRP URI in the use-path list in SDP. -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf > Of Ben Campbell > Sent: Monday, July 20, 2009 5:13 PM > > When MSRP relays are present, there will be two or more TCP > connections involved in a particular session. Which connection is > being negotiated via COMEDIA? > > I _think_ the answer is the connection between boundary relays--that > is, between the outermost relay of party A and the outermost relay of > party B. If one party uses a chain of relays, only the outer one would > require COMEDIA negotiation. I guess you could also look at this as > the connection that crosses domains, for some vague definition of > domain. > > There might be an interesting case here for when both parties share > the same relay. > > > _______________________________________________ > 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 ben@nostrum.com Tue Jul 21 16:19:35 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 32EE73A688F for ; Tue, 21 Jul 2009 16:19:35 -0700 (PDT) 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 zB1UnRSMzOXi for ; Tue, 21 Jul 2009 16:19:34 -0700 (PDT) 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 1B0973A6892 for ; Tue, 21 Jul 2009 16:19:08 -0700 (PDT) Received: from [10.0.1.2] (adsl-68-94-0-215.dsl.rcsntx.swbell.net [68.94.0.215]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6LNJ12H084649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2009 18:19:01 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> From: Ben Campbell To: Ben Campbell 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 v935.3) Date: Tue, 21 Jul 2009 18:18:55 -0500 References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 68.94.0.215 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 21 Jul 2009 23:19:35 -0000 On Jul 21, 2009, at 5:31 PM, Ben Campbell wrote: > > On Jul 21, 2009, at 5:14 PM, Hadriel Kaplan wrote: > >> >> I'm not sure I follow you - Comedia has a "connection:existing" >> attribute setting to re-use the same connection (e.g., in a new >> offer). Or do you mean of two separate media m= lines? > > You are right of course. Brain fart on my part. However, the draft > should probably mention how to apply this--the only reference I see > to connection:existing is in the ICE section. > > Wait, I remember why I brought this up--if a peer is behind an MSRP relay, how is it to know whether a reuseable connection already exists downstream of that relay? > >> >> -hadriel >> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>> Behalf >>> Of Ben Campbell >>> >>> How does the COMEDIA negotiation interact with the TCP-connection- >>> sharing features of MSRP? We negotiate sessions in the SDP offer/ >>> answer, not connections per se. COMEDIA implicitly assumes a one-to- >>> one correspondence between these, but MSRP explicitly allows >>> multiple >>> sessions to use the same TCP connection. >>> >>> I can see two approaches. One would be that the COMEDIA attributes >>> are >>> only relevant if you have to create a new connection. If a reusable >>> connection already exists, you just use it. Alternatively, we could >>> state that a connection is only reuseable if it's direction matches >>> the COMEDIA attributes, and if devices wanted to reuse an existing >>> connection, they would either omit COMEDIA entirely, or choose >>> COMEDIA >>> attributes that match the connection. >>> >>> Neither of those approaches seems obviously wrong to me. I suspect >>> there may be some traps here, though--we should analyze this pretty >>> closely. >>> >>> _______________________________________________ >>> 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 ben@nostrum.com Tue Jul 21 16:24: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 E8F913A688F for ; Tue, 21 Jul 2009 16:24:10 -0700 (PDT) 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 FVMkhfhvyWJq for ; Tue, 21 Jul 2009 16:24:10 -0700 (PDT) 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 8EF833A677C for ; Tue, 21 Jul 2009 16:24:09 -0700 (PDT) Received: from [10.0.1.2] (adsl-68-94-0-215.dsl.rcsntx.swbell.net [68.94.0.215]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6LNO3d5085028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2009 18:24:04 -0500 (CDT) (envelope-from ben@nostrum.com) 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 v935.3) Date: Tue, 21 Jul 2009 18:23:58 -0500 References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 68.94.0.215 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 21 Jul 2009 23:24:11 -0000 On Jul 21, 2009, at 6:02 PM, Christer Holmberg wrote: > Hi, > > Section 4.1.3 talks about the connection attribute. > Oops, you are right. My text search fu is weak today. But note my other comment concerning shared connections downstream of a relay. > Regards, > > Christer > > > ________________________________ > > From: simple-bounces@ietf.org on behalf of Ben Campbell > Sent: Wed 22/07/2009 00:31 > To: Hadriel Kaplan > Cc: Simple WG > Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections > > > > > On Jul 21, 2009, at 5:14 PM, Hadriel Kaplan wrote: > >> >> I'm not sure I follow you - Comedia has a "connection:existing" >> attribute setting to re-use the same connection (e.g., in a new >> offer). Or do you mean of two separate media m= lines? > > You are right of course. Brain fart on my part. However, the draft > should probably mention how to apply this--the only reference I see to > connection:existing is in the ICE section. > > > >> >> -hadriel >> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>> Behalf >>> Of Ben Campbell >>> >>> How does the COMEDIA negotiation interact with the TCP-connection- >>> sharing features of MSRP? We negotiate sessions in the SDP offer/ >>> answer, not connections per se. COMEDIA implicitly assumes a one-to- >>> one correspondence between these, but MSRP explicitly allows >>> multiple >>> sessions to use the same TCP connection. >>> >>> I can see two approaches. One would be that the COMEDIA attributes >>> are >>> only relevant if you have to create a new connection. If a reusable >>> connection already exists, you just use it. Alternatively, we could >>> state that a connection is only reuseable if it's direction matches >>> the COMEDIA attributes, and if devices wanted to reuse an existing >>> connection, they would either omit COMEDIA entirely, or choose >>> COMEDIA >>> attributes that match the connection. >>> >>> Neither of those approaches seems obviously wrong to me. I suspect >>> there may be some traps here, though--we should analyze this pretty >>> closely. >>> >>> _______________________________________________ >>> 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 christer.holmberg@ericsson.com Wed Jul 22 01:44: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 8120C3A67F1 for ; Wed, 22 Jul 2009 01:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, 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 mDYZen7hV6BS for ; Wed, 22 Jul 2009 01:44:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 337613A6842 for ; Wed, 22 Jul 2009 01:44:14 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-c2-4a66cd6b1313 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2B.AE.14528.B6DC66A4; Wed, 22 Jul 2009 10:27:23 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:27:23 +0200 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: Wed, 22 Jul 2009 10:27:22 +0200 Message-ID: In-Reply-To: <3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoKWb4s0PZLX9bGRIGNghz4ZiYobwAS7TYw References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com> <3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 22 Jul 2009 08:27:23.0286 (UTC) FILETIME=[3CB58B60:01CA0AA6] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 22 Jul 2009 08:44:16 -0000 Hi,=20 >>>I'm not sure I follow you - Comedia has a "connection:existing" =20 >>>attribute setting to re-use the same connection (e.g., in a new=20 >>>offer). Or do you mean of two separate media m=3D lines? >> >>You are right of course. Brain fart on my part. However, the draft=20 >>should probably mention how to apply this--the only reference I see to >>connection:existing is in the ICE section. > >Wait, I remember why I brought this up--if a peer is behind an MSRP =20 >relay, how is it to know whether a reuseable connection already exists >downstream of that relay? Even if it knows, how would it tell the relay whether to actually reuse that connection? I guess that would require some new information element. Note, however, that according to section 4.1.3, connection re-use is not used for initial offer/answers, only for re-negotiations. In any case, I can add something about this to my presentation. Regards, Christer >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On =20 >>> Behalf >>> Of Ben Campbell >>> >>> How does the COMEDIA negotiation interact with the TCP-connection- >>> sharing features of MSRP? We negotiate sessions in the SDP offer/ >>> answer, not connections per se. COMEDIA implicitly assumes a one-to- >>> one correspondence between these, but MSRP explicitly allows =20 >>> multiple >>> sessions to use the same TCP connection. >>> >>> I can see two approaches. One would be that the COMEDIA attributes =20 >>> are >>> only relevant if you have to create a new connection. If a reusable >>> connection already exists, you just use it. Alternatively, we could >>> state that a connection is only reuseable if it's direction matches >>> the COMEDIA attributes, and if devices wanted to reuse an existing >>> connection, they would either omit COMEDIA entirely, or choose =20 >>> COMEDIA >>> attributes that match the connection. >>> >>> Neither of those approaches seems obviously wrong to me. I suspect >>> there may be some traps here, though--we should analyze this pretty >>> closely. >>> >>> _______________________________________________ >>> 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 ag@ag-projects.com Wed Jul 22 08:41:45 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 3DD6D3A6949 for ; Wed, 22 Jul 2009 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 aQLetItZuyyA for ; Wed, 22 Jul 2009 08:41:43 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 05CE33A6901 for ; Wed, 22 Jul 2009 08:41:41 -0700 (PDT) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1MTdma-0005AS-QZ for simple@ietf.org; Wed, 22 Jul 2009 17:31:06 +0200 Message-Id: <2BF211FB-A70C-45BD-901D-C693906EF230@ag-projects.com> From: Adrian Georgescu To: simple@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-22--612959253 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 17:39:40 +0200 X-Mailer: Apple Mail (2.935.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 Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: [Simple] MSRP relay support in SIP clients 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, 22 Jul 2009 15:41:45 -0000 --Apple-Mail-22--612959253 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, Some feedback from the real world that might be useful. A list of MSRP clients that support the relay extension are listed here: SIP SIMPLE client library from http://sipsimpleclient.com Python SDK from http://download.ag-projects.com/SipClient/ Java SDK from https://msrp.dev.java.net C++ OPAL SDK from http://www.opalvoip.org (roadmap) SIP Communicator from http://sip-communicator.org (roadmap) Mercuro - fully featured IMS client from http://www.mercuro.net Radvision MSRP Client Developer Solution from http://radvision.com The list is maintained here: http://msrprelay.org/wiki/Clients There might be more but that's what I could locate or I have been personally in contact with. Regards, Adrian --Apple-Mail-22--612959253 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
  1. SIP SIMPLE client library = from http://msrprelay.org/wiki/Clien= ts

    There might be more but that's what I = could locate or I have been personally in contact = with.

    Regards,
    Adrian

    = --Apple-Mail-22--612959253-- From christer.holmberg@ericsson.com Sun Jul 26 01:02: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 2594C3A699F for ; Sun, 26 Jul 2009 01:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 Z9N0mIvfW1Yc for ; Sun, 26 Jul 2009 01:02:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DBC5D3A6832 for ; Sun, 26 Jul 2009 01:02:25 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc4ae000004197-51-4a6c0d91199e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 13.CD.16791.19D0C6A4; Sun, 26 Jul 2009 10:02:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Jul 2009 10:01:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0DC7.53540EC9" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 26 Jul 2009 10:01:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Connecting establishment according to 4975 (non-comedia) Thread-Index: AcoNx1OCwWw1RgcXTKuVkrxUXjmz1g== From: "Christer Holmberg" To: "Simple WG" X-OriginalArrivalTime: 26 Jul 2009 08:01:48.0866 (UTC) FILETIME=[53C6A220:01CA0DC7] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Connecting establishment according to 4975 (non-comedia) 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, 26 Jul 2009 08:02:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0DC7.53540EC9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, According to 4975, the session initiating endpoint is "active", ie it establishes the TCP connection. I can't find any text regarding session modification, though. If a client sends a re-INVITE, which would trigger a new TCP connection, who is responsible for establishing that TCP connection? I assume it would be the one initiating the re-INVITE, but I am not sure 4975 says anything about that. Or, have I missed it? Regards, Christer ------_=_NextPart_001_01CA0DC7.53540EC9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Connecting establishment according to 4975 (non-comedia)

    Hi,

    According to 4975, the session = initiating endpoint is "active", ie it establishes the TCP = connection.

    I can't find any text regarding session = modification, though. If a client sends a re-INVITE, which would trigger = a new TCP connection, who is responsible for establishing that TCP = connection? I assume it would be the one initiating the re-INVITE, but I = am not sure 4975 says anything about that.

    Or, have I missed it?

    Regards,

    Christer

    ------_=_NextPart_001_01CA0DC7.53540EC9-- From christer.holmberg@ericsson.com Mon Jul 27 06:27: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 C111628C1A2 for ; Mon, 27 Jul 2009 06:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_110=0.6, 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 aR2gMJsfzacD for ; Mon, 27 Jul 2009 06:27:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6631728C1A1 for ; Mon, 27 Jul 2009 06:27:26 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-2a-4a6dab3bc558 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 96.20.00514.B3BAD6A4; Mon, 27 Jul 2009 15:27:23 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 15:27:17 +0200 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: Mon, 27 Jul 2009 15:27:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoKWb4s0PZLX9bGRIGNghz4ZiYobwAS7TYwANWAIyA= References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com><3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Ben Campbell" X-OriginalArrivalTime: 27 Jul 2009 13:27:17.0063 (UTC) FILETIME=[F5E6C570:01CA0EBD] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 27 Jul 2009 13:27:27 -0000 Hi, More on this.=20 >>>>I'm not sure I follow you - Comedia has a "connection:existing" =20 >>>>attribute setting to re-use the same connection (e.g., in a new=20 >>>>offer). Or do you mean of two separate media m=3D lines? >>> >>>You are right of course. Brain fart on my part. However, the draft=20 >>>should probably mention how to apply this--the only reference I see to >>>connection:existing is in the ICE section. >> >>Wait, I remember why I brought this up--if a peer is behind an MSRP=20 >>relay, how is it to know whether a reuseable connection already exists >>downstream of that relay? > >Even if it knows, how would it tell the relay whether to actually reuse that connection? I guess that would require some=20 >new information element. We also need to think about the meaning of a=3Dconnection. According to my understanding (I guess we can verify that with the authors) of comedia, a=3Dconnection is not used to indicate that one can use "any existing TCP connection" towards a specific destination. My understanding is that a=3Dconnection is used during a session modification, to indicate whether the existing TCP connection for that specific session should be re-used (if possible) or not. So, for a specific session, the change of address would always trigger a new TCP connection - even if there exist TCP connections to the same address for OTHER sessions. Or? >Note, however, that according to section 4.1.3, connection re-use is not used for initial offer/answers, only for re- >negotiations. So, for session establishment, there is currently no difference between ACM and 4975 - if there is a TCP connection to a specific address, then use it.=20 For 4975, I assume the same applies for session modifications (eventhough 4975 doesn't explicitly says much about session modifications)... ACM currently specifies the usage of a=3Dconnection for session modifications, in accordance with comedia. So, IF we a=3Dconnection to work with relays, I guess we would need to provide the information to the relay inside the MSRP message. Again, I will add something about this to my presentation. Regards, Christer >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>> Behalf Of Ben Campbell >>> >>> How does the COMEDIA negotiation interact with the TCP-connection-=20 >>> sharing features of MSRP? We negotiate sessions in the SDP offer/=20 >>> answer, not connections per se. COMEDIA implicitly assumes a one-to- >>> one correspondence between these, but MSRP explicitly allows=20 >>> multiple sessions to use the same TCP connection. >>> >>> I can see two approaches. One would be that the COMEDIA attributes=20 >>> are only relevant if you have to create a new connection. If a=20 >>> reusable connection already exists, you just use it. Alternatively,=20 >>> we could state that a connection is only reuseable if it's direction >>> matches the COMEDIA attributes, and if devices wanted to reuse an=20 >>> existing connection, they would either omit COMEDIA entirely, or=20 >>> choose COMEDIA attributes that match the connection. >>> >>> Neither of those approaches seems obviously wrong to me. I suspect=20 >>> there may be some traps here, though--we should analyze this pretty=20 >>> closely. >>> >>> _______________________________________________ >>> 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 ben@nostrum.com Mon Jul 27 06:56:32 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 34A2928C17B for ; Mon, 27 Jul 2009 06:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, 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 IJfEOIQ8plwr for ; Mon, 27 Jul 2009 06:56:31 -0700 (PDT) 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 C22873A6C43 for ; Mon, 27 Jul 2009 06:56:30 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6RDuOZX014523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jul 2009 08:56:26 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <6C3ADBE4-5C3C-472E-9E29-254D14FE0703@nostrum.com> 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 v935.3) Date: Mon, 27 Jul 2009 15:56:24 +0200 References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com><3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 130.129.86.252 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 27 Jul 2009 13:56:32 -0000 On Jul 27, 2009, at 3:27 PM, Christer Holmberg wrote: > > Hi, > > More on this. > >>>>> I'm not sure I follow you - Comedia has a "connection:existing" >>>>> attribute setting to re-use the same connection (e.g., in a new >>>>> offer). Or do you mean of two separate media m= lines? >>>> >>>> You are right of course. Brain fart on my part. However, the draft >>>> should probably mention how to apply this--the only reference I see > to >>>> connection:existing is in the ICE section. >>> >>> Wait, I remember why I brought this up--if a peer is behind an MSRP >>> relay, how is it to know whether a reuseable connection already >>> exists >>> downstream of that relay? >> >> Even if it knows, how would it tell the relay whether to actually >> reuse > that connection? I guess that would require some >> new information element. > > We also need to think about the meaning of a=connection. > > According to my understanding (I guess we can verify that with the > authors) of comedia, a=connection is not used to indicate that one can > use "any existing TCP connection" towards a specific destination. > > My understanding is that a=connection is used during a session > modification, to indicate whether the existing TCP connection for that > specific session should be re-used (if possible) or not. So, for a > specific session, the change of address would always trigger a new TCP > connection - even if there exist TCP connections to the same address > for > OTHER sessions. > > Or? > >> Note, however, that according to section 4.1.3, connection re-use is > not used for initial offer/answers, only for re- >> negotiations. > My read of COMEDIA agrees with yours. It's not clear to me if the connection attribute applies at all--RFC4975 says if there is already an connection associated with the same host, port, and URI scheme, it SHOULD reuse it. COMEDIA doesn't appear to have been written with that sort of thing in mind. I am leaning (not strongly) towards suggesting we ignore the COMEDIA connection attribute and just do what an MSRP client would normally do, at least for this purpose. > > So, for session establishment, there is currently no difference > between > ACM and 4975 - if there is a TCP connection to a specific address, > then > use it. > > For 4975, I assume the same applies for session modifications > (eventhough 4975 doesn't explicitly says much about session > modifications)... You are right, it doesn't say much. I agree that the same would apply here. Also, I think all of this so far is the same with or without relays. > > ACM currently specifies the usage of a=connection for session > modifications, in accordance with comedia. > > So, IF we a=connection to work with relays, I guess we would need to > provide the information to the relay inside the MSRP message. I'm not sure I follow--what would you conceptually be telling the relay? > > Again, I will add something about this to my presentation. > > Regards, > > Christer > > >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf Of Ben Campbell >>>> >>>> How does the COMEDIA negotiation interact with the TCP-connection- >>>> sharing features of MSRP? We negotiate sessions in the SDP offer/ >>>> answer, not connections per se. COMEDIA implicitly assumes a one- >>>> to- > >>>> one correspondence between these, but MSRP explicitly allows >>>> multiple sessions to use the same TCP connection. >>>> >>>> I can see two approaches. One would be that the COMEDIA attributes >>>> are only relevant if you have to create a new connection. If a >>>> reusable connection already exists, you just use it. Alternatively, >>>> we could state that a connection is only reuseable if it's >>>> direction > >>>> matches the COMEDIA attributes, and if devices wanted to reuse an >>>> existing connection, they would either omit COMEDIA entirely, or >>>> choose COMEDIA attributes that match the connection. >>>> >>>> Neither of those approaches seems obviously wrong to me. I suspect >>>> there may be some traps here, though--we should analyze this pretty >>>> closely. >>>> >>>> _______________________________________________ >>>> 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 christer.holmberg@ericsson.com Mon Jul 27 07:06: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 DA0D228C222 for ; Mon, 27 Jul 2009 07:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.226 X-Spam-Level: X-Spam-Status: No, score=-5.226 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_110=0.6, 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 1EOIsrvnpwro for ; Mon, 27 Jul 2009 07:06:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9416328C125 for ; Mon, 27 Jul 2009 07:06:15 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-29-4a6db456fe43 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 20.51.20893.654BD6A4; Mon, 27 Jul 2009 16:06:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 16:05:49 +0200 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: Mon, 27 Jul 2009 16:05:48 +0200 Message-ID: In-Reply-To: <6C3ADBE4-5C3C-472E-9E29-254D14FE0703@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoOwgrlZq3PHlUXRyqdyygqDCAXGQAAQGFQ References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com><3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> <6C3ADBE4-5C3C-472E-9E29-254D14FE0703@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 27 Jul 2009 14:05:49.0334 (UTC) FILETIME=[581F5360:01CA0EC3] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 27 Jul 2009 14:06:17 -0000 >>So, for session establishment, there is currently no difference=20 >>between ACM and 4975 - if there is a TCP connection to a specific=20 >>ACM currently specifies the usage of a=3Dconnection for session=20 >>modifications, in accordance with comedia. >> >>So, IF we a=3Dconnection to work with relays, I guess we would need to = >>provide the information to the relay inside the MSRP message. > >I'm not sure I follow--what would you conceptually be telling the relay? You would be telling that a session modification has occurred (the remote address hasn't changed), and whether the relay can continue to use the existing TCP connection for the session, or whether it should create a new one. Ie the client would tell the relay exactly what the client was told in the session modification SDP. Regards, Christer >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>> Behalf Of Ben Campbell >>>> >>>> How does the COMEDIA negotiation interact with the TCP-connection-=20 >>>> sharing features of MSRP? We negotiate sessions in the SDP offer/=20 >>>> answer, not connections per se. COMEDIA implicitly assumes a one- >>>> to- > >>>> one correspondence between these, but MSRP explicitly allows=20 >>>> multiple sessions to use the same TCP connection. >>>> >>>> I can see two approaches. One would be that the COMEDIA attributes=20 >>>> are only relevant if you have to create a new connection. If a=20 >>>> reusable connection already exists, you just use it. Alternatively, >>>> we could state that a connection is only reuseable if it's=20 >>>> direction > >>>> matches the COMEDIA attributes, and if devices wanted to reuse an=20 >>>> existing connection, they would either omit COMEDIA entirely, or=20 >>>> choose COMEDIA attributes that match the connection. >>>> >>>> Neither of those approaches seems obviously wrong to me. I suspect=20 >>>> there may be some traps here, though--we should analyze this pretty >>>> closely. >>>> >>>> _______________________________________________ >>>> 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 ben@nostrum.com Mon Jul 27 07:14: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 E42DD3A69D5 for ; Mon, 27 Jul 2009 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, 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 Uk9yYq43kwem for ; Mon, 27 Jul 2009 07:14:27 -0700 (PDT) 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 CA4583A697D for ; Mon, 27 Jul 2009 07:14:26 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6REELg3015907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jul 2009 09:14:23 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <6B2410BF-EDAB-4C8C-B374-964AC13B9038@nostrum.com> 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 v935.3) Date: Mon, 27 Jul 2009 16:14:21 +0200 References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com><3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> <6C3ADBE4-5C3C-472E-9E29-254D14FE0703@nostrum.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 130.129.86.252 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 27 Jul 2009 14:14:28 -0000 On Jul 27, 2009, at 4:05 PM, Christer Holmberg wrote: >>> So, for session establishment, there is currently no difference >>> between ACM and 4975 - if there is a TCP connection to a specific >>> ACM currently specifies the usage of a=connection for session >>> modifications, in accordance with comedia. >>> >>> So, IF we a=connection to work with relays, I guess we would need to >>> provide the information to the relay inside the MSRP message. >> >> I'm not sure I follow--what would you conceptually be telling the > relay? > > You would be telling that a session modification has occurred (the > remote address hasn't changed), and whether the relay can continue to > use the existing TCP connection for the session, or whether it should > create a new one. > > Ie the client would tell the relay exactly what the client was told in > the session modification SDP. > So, why would we ever need to explicitly signal (in SDP) that a relay (or an endpoint for that matter) needs to create a new connection instead of reusing an appropriate existing one? From christer.holmberg@ericsson.com Mon Jul 27 07:28:14 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 052F928C284 for ; Mon, 27 Jul 2009 07:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_110=0.6, 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 zGCUarHSoNld for ; Mon, 27 Jul 2009 07:28:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CC6FF28C273 for ; Mon, 27 Jul 2009 07:28:12 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-58-4a6db97c2d7a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 71.54.00514.C79BD6A4; Mon, 27 Jul 2009 16:28:12 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 16:28:12 +0200 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: Mon, 27 Jul 2009 16:28:10 +0200 Message-ID: In-Reply-To: <6B2410BF-EDAB-4C8C-B374-964AC13B9038@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoOxJFm2zdh8tdvS96tzK7v/olOswAAVE7g References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com><3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> <6C3ADBE4-5C3C-472E-9E29-254D14FE0703@nostrum.com> <6B2410BF-EDAB-4C8C-B374-964AC13B9038@nostrum.com> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 27 Jul 2009 14:28:12.0275 (UTC) FILETIME=[7893DC30:01CA0EC6] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] COMEDIA vs MSRP Relays: Shared Connections 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, 27 Jul 2009 14:28:14 -0000 =20 Hi, >>>>So, for session establishment, there is currently no difference=20 >>>>between ACM and 4975 - if there is a TCP connection to a specific=20 >>>>ACM currently specifies the usage of a=3Dconnection for session=20 >>>>modifications, in accordance with comedia. >>>> >>>>So, IF we a=3Dconnection to work with relays, I guess we would need = to >>>>provide the information to the relay inside the MSRP message. >>> >>>I'm not sure I follow--what would you conceptually be telling the relay? >> >>You would be telling that a session modification has occurred (the=20 >>remote address hasn't changed), and whether the relay can continue to=20 >>use the existing TCP connection for the session, or whether it should=20 >>create a new one. >> >>Ie the client would tell the relay exactly what the client was told in >>the session modification SDP. > >So, why would we ever need to explicitly signal (in SDP) that a relay (or an endpoint for that matter) needs to create a >new connection instead of reusing an appropriate existing one? That you would have to ask the people who defined the a=3Dconnection attribute in the first place :) The ACM simply uses it in order to be compliant with comedia. Unfortunately I don't remember the use-case discussions etc from the time comedia was done, but I guess we can check whether the comedia spec says something about it.=20 Regards, Christer From ben@estacado.net Mon Jul 27 08: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 B2B9028C241 for ; Mon, 27 Jul 2009 08:21:27 -0700 (PDT) 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 jqORzXIa1E7Z for ; Mon, 27 Jul 2009 08:21:27 -0700 (PDT) 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 942E93A6A7B for ; Mon, 27 Jul 2009 08:21:26 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6RFLKiU090640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Jul 2009 10:21:25 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 17:21:19 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [Simple] simple-chat status 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, 27 Jul 2009 15:21:27 -0000 (as SIMPLE chair) Hi, We originally started work on draft-ietf-simple-chat back in 2007, with the idea that we could finish it quickly, and have something that works prior to completion of similar, but more general work in XCON. It's been two years now, so we clearly didn't finish it quickly, and it's been sitting without update or discussion since last spring. (Please don't take that as a complaint against the authors. I don't mean it that way--we're all busy here.) We are looking at how to get the draft moving again, but there's an important question we should address first: Is simple-chat still relevant? Should we take the effort to fix it, or should we shoot that milestone in the head? To recap, we WGLC'd simple-chat last April. There were non-trivial (but not necessarily earth-shattering) issues brought up in the feedback. That is, there's still at least a bit of work left to do on it. Perhaps Adam or Alan could comment on the status of the related work in XCON? Thanks! Ben. From AVSHALOM@il.ibm.com Mon Jul 27 08:47:02 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 AD57D28C185 for ; Mon, 27 Jul 2009 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uGLQubbCy09J for ; Mon, 27 Jul 2009 08:47:01 -0700 (PDT) Received: from mtagate7.de.ibm.com (mtagate7.de.ibm.com [195.212.29.156]) by core3.amsl.com (Postfix) with ESMTP id 4ACD83A6AD4 for ; Mon, 27 Jul 2009 08:47:01 -0700 (PDT) Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate7.de.ibm.com (8.14.3/8.13.8) with ESMTP id n6RFknGt057324 for ; Mon, 27 Jul 2009 15:46:49 GMT Received: from d12av06.megacenter.de.ibm.com (d12av06.megacenter.de.ibm.com [9.149.165.230]) by d12nrmr1707.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6RFkoC82957374 for ; Mon, 27 Jul 2009 17:46:50 +0200 Received: from d12av06.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av06.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n6RFkoTN019239 for ; Mon, 27 Jul 2009 17:46:50 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.167.114] (may be forged)) by d12av06.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n6RFkoF5019236 for ; Mon, 27 Jul 2009 17:46:50 +0200 In-Reply-To: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> To: Simple WG MIME-Version: 1.0 X-KeepSent: 424D15AD:10A0A35A-C2257600:0055C86A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Mon, 27 Jul 2009 18:46:50 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 27/07/2009 18:46:49, Serialize complete at 27/07/2009 18:46:49 Content-Type: multipart/alternative; boundary="=_alternative 00568306C2257600_=" Subject: Re: [Simple] simple-chat status 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, 27 Jul 2009 15:47:02 -0000 This is a multipart message in MIME format. --=_alternative 00568306C2257600_= Content-Type: text/plain; charset="US-ASCII" Something that I really see missing in the area of SIP presence and IM and is related to simple-chat is the enablement of chat rooms and interdomain chat rooms in particular. I do not know what should be the route of achieving this but it seems something that is really missing for SIP presence and IM deployments. If there is a need for someone to help here, I am willing to help. --Avshalom From: Ben Campbell To: Simple WG Date: 27/07/2009 06:21 PM Subject: [Simple] simple-chat status Sent by: simple-bounces@ietf.org (as SIMPLE chair) Hi, We originally started work on draft-ietf-simple-chat back in 2007, with the idea that we could finish it quickly, and have something that works prior to completion of similar, but more general work in XCON. It's been two years now, so we clearly didn't finish it quickly, and it's been sitting without update or discussion since last spring. (Please don't take that as a complaint against the authors. I don't mean it that way--we're all busy here.) We are looking at how to get the draft moving again, but there's an important question we should address first: Is simple-chat still relevant? Should we take the effort to fix it, or should we shoot that milestone in the head? To recap, we WGLC'd simple-chat last April. There were non-trivial (but not necessarily earth-shattering) issues brought up in the feedback. That is, there's still at least a bit of work left to do on it. Perhaps Adam or Alan could comment on the status of the related work in XCON? Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --=_alternative 00568306C2257600_= Content-Type: text/html; charset="US-ASCII" Something that I really see missing in the area of SIP presence and IM and is
    related to simple-chat is the enablement of chat rooms and interdomain chat
    rooms in particular.

    I do not know what should be the route of achieving this but it seems something
    that is really missing for SIP presence and IM deployments.

    If there is a need for someone to help here, I am willing to help.

    --Avshalom


    From: Ben Campbell <ben@estacado.net>
    To: Simple WG <simple@ietf.org>
    Date: 27/07/2009 06:21 PM
    Subject: [Simple] simple-chat status
    Sent by: simple-bounces@ietf.org




    (as SIMPLE chair)

    Hi,

    We originally started work on draft-ietf-simple-chat back in 2007,  
    with the idea that we could finish it quickly, and have something that  
    works prior to completion of similar, but more general work in XCON.

    It's been two years now, so we clearly didn't finish it quickly, and  
    it's been sitting without update or discussion since last spring.  
    (Please don't take that as a complaint against the authors. I don't  
    mean it that way--we're all busy here.) We are looking at how to get  
    the draft moving again, but there's an important question we should  
    address first:

    Is simple-chat still relevant? Should we take the effort to fix it, or  
    should we shoot that milestone in the head?

    To recap, we WGLC'd simple-chat last April. There were non-trivial  
    (but not necessarily earth-shattering) issues brought up in the  
    feedback. That is, there's still at least a bit of work left to do on  
    it.

    Perhaps Adam or Alan could comment on the status of the related work  
    in XCON?

    Thanks!

    Ben.
    _______________________________________________
    Simple mailing list
    Simple@ietf.org
    https://www.ietf.org/mailman/listinfo/simple
    --=_alternative 00568306C2257600_=-- From adam@nostrum.com Mon Jul 27 09:00: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 2262728C294 for ; Mon, 27 Jul 2009 09:00:18 -0700 (PDT) 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 Ao7of5MJHj0w for ; Mon, 27 Jul 2009 09:00:17 -0700 (PDT) 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 824BE3A6C9C for ; Mon, 27 Jul 2009 09:00:11 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6RFxqe0024118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 10:59:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A6DCEF7.6050600@nostrum.com> Date: Mon, 27 Jul 2009 17:59:51 +0200 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Ben Campbell References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> In-Reply-To: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] simple-chat status 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, 27 Jul 2009 16:00:18 -0000 Ben Campbell wrote: > We originally started work on draft-ietf-simple-chat back in 2007, > with the idea that we could finish it quickly, and have something that > works prior to completion of similar, but more general work in XCON. > > It's been two years now, so we clearly didn't finish it quickly, and > it's been sitting without update or discussion since last spring. > (Please don't take that as a complaint against the authors. I don't > mean it that way--we're all busy here.) We are looking at how to get > the draft moving again, but there's an important question we should > address first: > > Is simple-chat still relevant? Should we take the effort to fix it, or > should we shoot that milestone in the head? > > To recap, we WGLC'd simple-chat last April. There were non-trivial > (but not necessarily earth-shattering) issues brought up in the > feedback. That is, there's still at least a bit of work left to do on it. > > Perhaps Adam or Alan could comment on the status of the related work > in XCON? It's moving along slowly, but (relatively) steadily. Basically, it's a turtle racing a snail, and the CCMP turtle is gaining on the SIMPLE-CHAT snail. I personally question the value of the SIMPLE-CHAT work at this point, because I can't imagine it being published more than about 3 months ahead of CCMP (which will make SIMPLE-CHAT a moot point). /a From ben@estacado.net Tue Jul 28 01:37:19 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 596B93A6853 for ; Tue, 28 Jul 2009 01:37:19 -0700 (PDT) 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.001, 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 sIcV1Ktsv0HZ for ; Tue, 28 Jul 2009 01:37:18 -0700 (PDT) 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 30C463A6995 for ; Tue, 28 Jul 2009 01:37:17 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6S8b7nE056757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jul 2009 03:37:13 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Avshalom Houri In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4--119912688 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 10:37:06 +0200 References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> X-Mailer: Apple Mail (2.935.3) Cc: Simple WG Subject: Re: [Simple] simple-chat status 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, 28 Jul 2009 08:37:19 -0000 --Apple-Mail-4--119912688 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Avshalom--comments inline: > Something that I really see missing in the area of SIP presence and > IM and is > related to simple-chat is the enablement of chat rooms and > interdomain chat > rooms in particular. > We're not contemplating tossing out the chat-room concept. The question is, whether we should continue with the simple-chat draft, or defer to the more general solutions being worked in XCON. Can you elaborate on your inter-domain comment? What do you see as missing? Thanks! Ben. --Apple-Mail-4--119912688 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
    Hi Avshalom--comments inline:

    Something that I really see missing in the area of SIP presence and IM and is
    related to simple-chat is the enablement of chat rooms and interdomain chat
    rooms in particular.


    We're not contemplating tossing out the chat-room concept. The question is, whether we should continue with the simple-chat draft, or defer to the more general solutions being worked in XCON.

    Can you elaborate on your inter-domain comment? What do you see as missing?

    Thanks!

    Ben.

    --Apple-Mail-4--119912688-- From HKaplan@acmepacket.com Tue Jul 28 08:47:36 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 588343A70BC for ; Tue, 28 Jul 2009 08:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 v+4gIJPzKbgg for ; Tue, 28 Jul 2009 08:47:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5B17A3A70BD for ; Tue, 28 Jul 2009 08:47:34 -0700 (PDT) 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.375.2; Tue, 28 Jul 2009 11:47:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 28 Jul 2009 11:47:35 -0400 From: Hadriel Kaplan To: Ben Campbell , Christer Holmberg Date: Tue, 28 Jul 2009 11:47:35 -0400 Thread-Topic: [Simple] COMEDIA vs MSRP Relays: Shared Connections Thread-Index: AcoOxJGGYr2hqkAQR82UvMdtGk1lRAA1a8Ug Message-ID: References: <64763153-4233-4D95-802D-62108F4241D9@nostrum.com><3072AE58-452E-4AB7-A1F6-4189B0AB08EF@nostrum.com> <6C3ADBE4-5C3C-472E-9E29-254D14FE0703@nostrum.com> <6B2410BF-EDAB-4C8C-B374-964AC13B9038@nostrum.com> In-Reply-To: <6B2410BF-EDAB-4C8C-B374-964AC13B9038@nostrum.com> 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] COMEDIA vs MSRP Relays: Shared Connections 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, 28 Jul 2009 15:47:36 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > > So, why would we ever need to explicitly signal (in SDP) that a relay > (or an endpoint for that matter) needs to create a new connection > instead of reusing an appropriate existing one? I don't know why the authors did it, but I can guess or some up with a plau= sible story: Comedia was supposed to be agnostic of the "media" being sent = or its usage. So imagine if you were doing file transfers with SIP. If yo= u sent a re-Invite for a new file, you'd want a new TCP connection for it, = if your transfer did not have a framing/control layer in that TCP connectio= n itself to keep the files apart. -hadriel From ben@nostrum.com Wed Jul 29 02:35:42 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 B5A703A6F1D for ; Wed, 29 Jul 2009 02:35:42 -0700 (PDT) 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 aQY+lcDGz4C7 for ; Wed, 29 Jul 2009 02:35:42 -0700 (PDT) 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 A64E13A6E8C for ; Wed, 29 Jul 2009 02:35:41 -0700 (PDT) Received: from [10.43.1.51] ([212.112.167.85]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6T9ZcF1018416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 29 Jul 2009 04:35:41 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 11:35:32 +0200 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 212.112.167.85 is authenticated by a trusted mechanism) Subject: [Simple] Minute Takers 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, 29 Jul 2009 09:35:42 -0000 If we could get a couple of volunteer minute takers and a jabber scribe in advance of this afternoon's meeting, it would let us get started that much quicker. If you are willing, please send email. Thanks! Ben. From stpeter@stpeter.im Wed Jul 29 02:53: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 BB83C3A6940 for ; Wed, 29 Jul 2009 02:53:59 -0700 (PDT) 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 PwR6ENlM2rji for ; Wed, 29 Jul 2009 02:53:59 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 094383A68D7 for ; Wed, 29 Jul 2009 02:53:59 -0700 (PDT) Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A4D64007B; Wed, 29 Jul 2009 03:53:45 -0600 (MDT) Message-ID: <4A701C26.2080501@stpeter.im> Date: Wed, 29 Jul 2009 11:53:42 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: Re: [Simple] Minute Takers 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, 29 Jul 2009 09:53:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/29/09 11:35 AM, Ben Campbell wrote: > If we could get a couple of volunteer minute takers and a jabber scribe > in advance of this afternoon's meeting, it would let us get started that > much quicker. > > If you are willing, please send email. I'm happy to be the jabber scribe. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwHCYACgkQNL8k5A2w/vzLZQCgt41nUNbL/CMX89Nqx8iej9JU YeoAn02yClOluBMZWEK0S6SwAecQ7dXI =3Y3C -----END PGP SIGNATURE----- From ben@estacado.net Wed Jul 29 09:30: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 854B93A6FEC for ; Wed, 29 Jul 2009 09:30:23 -0700 (PDT) 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 H0bMQfG9nxHK for ; Wed, 29 Jul 2009 09:30:22 -0700 (PDT) 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 5307C3A6FB1 for ; Wed, 29 Jul 2009 09:30:21 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6TGUFXf080450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 29 Jul 2009 11:30:21 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <100F57C5-18A4-4A64-A4CF-5D4D588D2F07@estacado.net> From: Ben Campbell To: Simple WG 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 v935.3) Date: Wed, 29 Jul 2009 18:30:14 +0200 References: X-Mailer: Apple Mail (2.935.3) Subject: Re: [Simple] Minute Takers 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, 29 Jul 2009 16:30:23 -0000 Many thanks to Dean and Peter for taking minutes and jabber scribing, respectively! On Jul 29, 2009, at 11:35 AM, Ben Campbell wrote: > If we could get a couple of volunteer minute takers and a jabber > scribe in advance of this afternoon's meeting, it would let us get > started that much quicker. > > If you are willing, please send email. > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Wed Jul 29 12:11:01 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 EBF383A6E40 for ; Wed, 29 Jul 2009 12:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=0.929, 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 Lly8WYIduV6y for ; Wed, 29 Jul 2009 12:11:01 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id EE5CD3A6876 for ; Wed, 29 Jul 2009 12:11:00 -0700 (PDT) Received: by ewy10 with SMTP id 10so214976ewy.37 for ; Wed, 29 Jul 2009 12:11:00 -0700 (PDT) Received: by 10.210.11.13 with SMTP id 13mr398360ebk.90.1248894659983; Wed, 29 Jul 2009 12:10:59 -0700 (PDT) Received: from ibc-laptop.localnet (19.216.218.87.dynamic.jazztel.es [87.218.216.19]) by mx.google.com with ESMTPS id 28sm1526908eyg.10.2009.07.29.12.10.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 12:10:59 -0700 (PDT) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Wed, 29 Jul 2009 21:10:57 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.28-11-generic; KDE/4.2.98; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200907292110.57576.ibc@aliax.net> Subject: [Simple] XCAP: Fetching element namespaces and prefixes 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, 29 Jul 2009 19:11:02 -0000 Hi, as far as I understand by reading: http://tools.ietf.org/html/rfc4825#section-7.10 http://tools.ietf.org/html/rfc4825#section-10 if a XCAP client wants to create/repalce an element, the body of the PUT=20 request must use the same namespaces and prefixes as those used in the=20 document stored in the server. But the URL in the PUT request could use cus= tom=20 prefixes if it includes a XMLNS query as usual ?xmlns(ccpp=3Durn... So, if the client doesn't have a local cached version of the document (it=20 doesn't know the namespace prefixes used in the stored document) it must fe= tch=20 the element namespaces prior to the PUT operation. So let's assume the document in the server uses the following namespaces: cp=3Durn:ietf:params:xml:ns:common-policy pr=3Durn:ietf:params:xml:ns:pres-rules Let's suppose a query to fetch the namespaces for an element into the document stored in the server: =2D--------- GET /xcap-root/pres-rules/users/alice@domain.net/pres- rules/~~/ccpp:ruleset/ccpp:rule%5b@id=3D%22pres_whitelist%22%5d/ccpp:condit= ions/ccpp:identity/namespace::* ?xmlns(ccpp=3Durn:ietf:params:xml:ns:common-policy) HTTP/1.1 =2D-------------- It should retrieve from the server a reply containing the namespaces and prefixes of the stored document for the element requested: =2D-------------- HTTP/1.1 200 OK Content-Type: application/xcap-ns+xml =2D--------------- With this data, the client could apply the correct namespace prefixes to the body of a PUT request, this is: "cp" and "pr". Is it correct? is the body of the response the correct one? Thanks a lot. =2D-=20 I=C3=B1aki Baz Castillo From hisham.khartabil@gmail.com Wed Jul 29 17:06: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 231B43A7100 for ; Wed, 29 Jul 2009 17:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 HIfmqhpDdKA8 for ; Wed, 29 Jul 2009 17:06:54 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 49A043A690A for ; Wed, 29 Jul 2009 17:06:54 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so303440wff.31 for ; Wed, 29 Jul 2009 17:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=B+2oj7TLUd+CiJoG8sCot2hiDiHRcOsudTgz79BTg+U=; b=FQovz6sSnO+g4p/tmwyZV2J8KbmFenswWTw548l48ItgRAXXHjw83Ed32keM6Q7vLZ 2kIRI0y560gendLI9gTueryMeohM6GABs4w6XmSOSsmeI/Uk/41DpIF7Y7LTOBK4Pzjf 4p8UrkpBQso3MHzCf9ZPEpcoWeczZFJTic/MA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xNCc7+g2QFhB7cpxLWsZFUTXwIfA325RkYyN7ce6X1PyOJeGvKydkR6wMSjYXNpQ/9 tRsJLygfn0Sz0kKG6ldR45s7yYrXptb4+cDXia6J6sLAXjeqrENzWyEbQy6dfIiVxoZs wCgiIg2+71gUrsnqBWcbs3XHqEWgo5/YRWOm0= MIME-Version: 1.0 Received: by 10.142.135.16 with SMTP id i16mr29494wfd.261.1248912413977; Wed, 29 Jul 2009 17:06:53 -0700 (PDT) In-Reply-To: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> Date: Thu, 30 Jul 2009 10:06:53 +1000 Message-ID: <66cd252f0907291706g24a40952l939391567f42da05@mail.gmail.com> From: Hisham Khartabil To: Ben Campbell Content-Type: multipart/alternative; boundary=000e0cd32872ca6d94046fe11442 Cc: Simple WG Subject: Re: [Simple] simple-chat status 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, 30 Jul 2009 00:06:55 -0000 --000e0cd32872ca6d94046fe11442 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe we should finish what we already started. CCMP does not interest me. Hisham 2009/7/28 Ben Campbell > (as SIMPLE chair) > > Hi, > > We originally started work on draft-ietf-simple-chat back in 2007, with the > idea that we could finish it quickly, and have something that works prior to > completion of similar, but more general work in XCON. > > It's been two years now, so we clearly didn't finish it quickly, and it's > been sitting without update or discussion since last spring. (Please don't > take that as a complaint against the authors. I don't mean it that > way--we're all busy here.) We are looking at how to get the draft moving > again, but there's an important question we should address first: > > Is simple-chat still relevant? Should we take the effort to fix it, or > should we shoot that milestone in the head? > > To recap, we WGLC'd simple-chat last April. There were non-trivial (but not > necessarily earth-shattering) issues brought up in the feedback. That is, > there's still at least a bit of work left to do on it. > > Perhaps Adam or Alan could comment on the status of the related work in > XCON? > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --000e0cd32872ca6d94046fe11442 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe we should finish what we already started. CCMP does not interest = me.

    Hisham

    2009/7/28 Ben Campbell = <ben@estacado.net<= /a>>
    (as SIMPLE chair)=

    Hi,

    We originally started work on draft-ietf-simple-chat back in 2007, with the= idea that we could finish it quickly, and have something that works prior = to completion of similar, but more general work in XCON.

    It's been two years now, so we clearly didn't finish it quickly, an= d it's been sitting without update or discussion since last spring. (Pl= ease don't take that as a complaint against the authors. I don't me= an it that way--we're all busy here.) We are looking at how to get the = draft moving again, but there's an important question we should address= first:

    Is simple-chat still relevant? Should we take the effort to fix it, or shou= ld we shoot that milestone in the head?

    To recap, we WGLC'd simple-chat last April. There were non-trivial (but= not necessarily earth-shattering) issues brought up in the feedback. That = is, there's still at least a bit of work left to do on it.

    Perhaps Adam or Alan could comment on the status of the related work in XCO= N?

    Thanks!

    Ben.
    _______________________________________________
    Simple mailing list
    Simple@ietf.org = https://www.ietf.org/mailman/listinfo/simple

    --000e0cd32872ca6d94046fe11442-- From ben@estacado.net Thu Jul 30 05:40:48 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 2AC8028C26E for ; Thu, 30 Jul 2009 05:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 F+iUUIfggP3B for ; Thu, 30 Jul 2009 05:40:47 -0700 (PDT) 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 7C67828C27A for ; Thu, 30 Jul 2009 05:40:46 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6UCecOS093433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jul 2009 07:40:44 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <0811196B-D58E-4B3C-9A0E-BC0BF5AEAF5C@estacado.net> From: Ben Campbell To: Hisham Khartabil In-Reply-To: <66cd252f0907291706g24a40952l939391567f42da05@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-67498391 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 14:40:37 +0200 References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> <66cd252f0907291706g24a40952l939391567f42da05@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Simple WG Subject: Re: [Simple] simple-chat status 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, 30 Jul 2009 12:40:48 -0000 --Apple-Mail-6-67498391 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Hisham, To clarify: You plan to implement, or otherwise have a need for simple- chat, and a CCMP solution would not work for you? On Jul 30, 2009, at 2:06 AM, Hisham Khartabil wrote: > I believe we should finish what we already started > CCMP does not interest me. > > Hisham > > 2009/7/28 Ben Campbell > (as SIMPLE chair) > > Hi, > > We originally started work on draft-ietf-simple-chat back in 2007, > with the idea that we could finish it quickly, and have something > that works prior to completion of similar, but more general work in > XCON. > > It's been two years now, so we clearly didn't finish it quickly, and > it's been sitting without update or discussion since last spring. > (Please don't take that as a complaint against the authors. I don't > mean it that way--we're all busy here.) We are looking at how to get > the draft moving again, but there's an important question we should > address first: > > Is simple-chat still relevant? Should we take the effort to fix it, > or should we shoot that milestone in the head? > > To recap, we WGLC'd simple-chat last April. There were non-trivial > (but not necessarily earth-shattering) issues brought up in the > feedback. That is, there's still at least a bit of work left to do > on it. > > Perhaps Adam or Alan could comment on the status of the related work > in XCON? > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --Apple-Mail-6-67498391 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
    Hi = Hisham,

    To clarify: You plan to implement, or = otherwise have a need for simple-chat, and a CCMP solution would not = work for you?

    On Jul 30, 2009, at 2:06 AM, Hisham = Khartabil wrote:

    I believe we should finish what we already = started
    CCMP does not interest = me.

    Hisham

    2009/7/28 Ben = Campbell <ben@estacado.net>
    =
    (as = SIMPLE chair)

    Hi,

    We originally started work on = draft-ietf-simple-chat back in 2007, with the idea that we could finish = it quickly, and have something that works prior to completion of = similar, but more general work in XCON.

    It's been two years = now, so we clearly didn't finish it quickly, and it's been sitting = without update or discussion since last spring. (Please don't take that = as a complaint against the authors. I don't mean it that way--we're all = busy here.) We are looking at how to get the draft moving again, but = there's an important question we should address first:

    Is = simple-chat still relevant? Should we take the effort to fix it, or = should we shoot that milestone in the head?

    To recap, we WGLC'd = simple-chat last April. There were non-trivial (but not necessarily = earth-shattering) issues brought up in the feedback. That is, there's = still at least a bit of work left to do on it.

    Perhaps Adam or = Alan could comment on the status of the related work in XCON?

    = Thanks!

    Ben.
    = _______________________________________________
    Simple mailing = list
    Simple@ietf.org
    https://www.ietf.org/mailman/listinfo/simple
    =


    = --Apple-Mail-6-67498391-- From ben@nostrum.com Thu Jul 30 05:45:33 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 4C0313A6FB0 for ; Thu, 30 Jul 2009 05:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, 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 v9KxBVl+PIhv for ; Thu, 30 Jul 2009 05:45:32 -0700 (PDT) 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 C9F633A6BE2 for ; Thu, 30 Jul 2009 05:45:31 -0700 (PDT) Received: from dhcp-56fc.meeting.ietf.org (dhcp-56fc.meeting.ietf.org [130.129.86.252] (may be forged)) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6UCjTT0056262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 30 Jul 2009 07:45:31 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> From: Ben Campbell To: Simple WG In-Reply-To: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 14:45:29 +0200 References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 130.129.86.252 is authenticated by a trusted mechanism) Subject: Re: [Simple] simple-chat status 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, 30 Jul 2009 12:45:33 -0000 (As chair) The sense of the room in Stockholm was that we no longer needed the simple-chat as it currently exists, but that we did need to make sure we preserved the information in it that describes how a focus works with MSRP and message/cpim, whether as a scaled down version of simple- chat or as an addition to the XCON documents. I'd like to make a consensus call on the list to confirm or deny that approach. (I just saw Hisham's email--what do other's think?) Thanks! ben. On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: > (as SIMPLE chair) > > Hi, > > We originally started work on draft-ietf-simple-chat back in 2007, > with the idea that we could finish it quickly, and have something > that works prior to completion of similar, but more general work in > XCON. > > It's been two years now, so we clearly didn't finish it quickly, and > it's been sitting without update or discussion since last spring. > (Please don't take that as a complaint against the authors. I don't > mean it that way--we're all busy here.) We are looking at how to get > the draft moving again, but there's an important question we should > address first: > > Is simple-chat still relevant? Should we take the effort to fix it, > or should we shoot that milestone in the head? > > To recap, we WGLC'd simple-chat last April. There were non-trivial > (but not necessarily earth-shattering) issues brought up in the > feedback. That is, there's still at least a bit of work left to do > on it. > > Perhaps Adam or Alan could comment on the status of the related work > in XCON? > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Thu Jul 30 06:37:46 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 DD37928C284 for ; Thu, 30 Jul 2009 06:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rm6fXPdB4E89 for ; Thu, 30 Jul 2009 06:37:46 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id C1B6628C23E for ; Thu, 30 Jul 2009 06:37:45 -0700 (PDT) Received: by fxm26 with SMTP id 26so676278fxm.42 for ; Thu, 30 Jul 2009 06:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.106.14 with SMTP id v14mr752172fao.49.1248961064684; Thu, 30 Jul 2009 06:37:44 -0700 (PDT) Date: Thu, 30 Jul 2009 15:37:44 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Simple] [OT] Ruby XCAPClient released 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, 30 Jul 2009 13:37:46 -0000 Hi, if such announcement is not appropriate in this list please accept my apologies. For those interested in building SIMPLE rich presence applications in Ruby language I've released a GPLv3 library called XCAPClient: http://xcapclient.rubyforge.org/ http://dev.sipdoc.net/projects/ruby-xcapclient/wiki/ Ruby XCAPClient -------------------------------------------------- A XCAP client library written in Ruby language. XCAP (RFC 4825) is a protocol on top of HTTP which allows a client (usually a VoIP/SIP device) to manipulate the contents of Presence Information Data Format (PIDF) based presence documents. These documents are stored in a server in XML format. Ruby xcapclient library implements the XCAP protocol in client side, allowing the applications to get, store, modify and delete XML documents in the server. =3D=3D Features * Fetch, create/replace and delete a document. * Fetch, create/replace and delete a document element (XML node). * Fetch, create/replace and delete an element attribute. * Full configurable parameters allowing customized fields for each XCAP application, such auid, XML namespace, MIME-Type, scope (:user or :global) and default document name ("index" if not set). * Fetch the namespaces and prefixes of a document node as they are used in the server. * Manage of multiple documents per XCAP application. * Fetch the XCAP server auids, extensions and namespaces ("xcap-caps" application). * SSL. * Digest and Basic HTTP authentication. * Raise custom Ruby exception for each HTTP error response. -------------------------------------------------- Regards. --=20 I=C3=B1aki Baz Castillo From AVSHALOM@il.ibm.com Thu Jul 30 06:56:39 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 E84B43A6921; Thu, 30 Jul 2009 06:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iab-0lItYo7Z; Thu, 30 Jul 2009 06:56:39 -0700 (PDT) Received: from mtagate7.de.ibm.com (mtagate7.de.ibm.com [195.212.29.156]) by core3.amsl.com (Postfix) with ESMTP id 7A2843A6802; Thu, 30 Jul 2009 06:56:38 -0700 (PDT) Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate7.de.ibm.com (8.14.3/8.13.8) with ESMTP id n6UDuNTK621488; Thu, 30 Jul 2009 13:56:23 GMT Received: from d12av05.megacenter.de.ibm.com (d12av05.megacenter.de.ibm.com [9.149.165.216]) by d12nrmr1507.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6UDuNfG3399756; Thu, 30 Jul 2009 15:56:23 +0200 Received: from d12av05.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n6UDuNaJ015690; Thu, 30 Jul 2009 15:56:23 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n6UDuNTM015687; Thu, 30 Jul 2009 15:56:23 +0200 In-Reply-To: <3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> <3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> To: Ben Campbell MIME-Version: 1.0 X-KeepSent: 5C24065F:C891852E-C2257603:004819C6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Thu, 30 Jul 2009 16:56:21 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 30/07/2009 16:56:22, Serialize complete at 30/07/2009 16:56:22 Content-Type: multipart/alternative; boundary="=_alternative 004C11D5C2257603_=" Cc: Simple WG , simple-bounces@ietf.org Subject: Re: [Simple] simple-chat status 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, 30 Jul 2009 13:56:40 -0000 This is a multipart message in MIME format. --=_alternative 004C11D5C2257603_= Content-Type: text/plain; charset="US-ASCII" I agree with the room sense approach. Publishing both in the same timeframe, may create even more confusion in this area. I am not even sure that providing both will not raise questions from the IESG when we will reach to that stage. --Avshalom From: Ben Campbell To: Simple WG Date: 30/07/2009 03:45 PM Subject: Re: [Simple] simple-chat status Sent by: simple-bounces@ietf.org (As chair) The sense of the room in Stockholm was that we no longer needed the simple-chat as it currently exists, but that we did need to make sure we preserved the information in it that describes how a focus works with MSRP and message/cpim, whether as a scaled down version of simple- chat or as an addition to the XCON documents. I'd like to make a consensus call on the list to confirm or deny that approach. (I just saw Hisham's email--what do other's think?) Thanks! ben. On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: > (as SIMPLE chair) > > Hi, > > We originally started work on draft-ietf-simple-chat back in 2007, > with the idea that we could finish it quickly, and have something > that works prior to completion of similar, but more general work in > XCON. > > It's been two years now, so we clearly didn't finish it quickly, and > it's been sitting without update or discussion since last spring. > (Please don't take that as a complaint against the authors. I don't > mean it that way--we're all busy here.) We are looking at how to get > the draft moving again, but there's an important question we should > address first: > > Is simple-chat still relevant? Should we take the effort to fix it, > or should we shoot that milestone in the head? > > To recap, we WGLC'd simple-chat last April. There were non-trivial > (but not necessarily earth-shattering) issues brought up in the > feedback. That is, there's still at least a bit of work left to do > on it. > > Perhaps Adam or Alan could comment on the status of the related work > in XCON? > > Thanks! > > Ben. > _______________________________________________ > 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 --=_alternative 004C11D5C2257603_= Content-Type: text/html; charset="US-ASCII" I agree with the room sense approach.  Publishing both in the same timeframe, may create even more confusion in this area. I am not even sure that providing both will not raise questions from the IESG when we will reach to that stage.

    --Avshalom


    From: Ben Campbell <ben@nostrum.com>
    To: Simple WG <simple@ietf.org>
    Date: 30/07/2009 03:45 PM
    Subject: Re: [Simple] simple-chat status
    Sent by: simple-bounces@ietf.org




    (As chair)

    The sense of the room in Stockholm was that we no longer needed the  
    simple-chat as it currently exists, but that we did need to make sure  
    we preserved the information in it that describes how a focus works  
    with MSRP and message/cpim, whether as a scaled down version of simple-
    chat or as an addition to the XCON documents.

    I'd like to make a consensus call on the list to confirm or deny that  
    approach. (I just saw Hisham's email--what do other's think?)

    Thanks!

    ben.

    On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote:

    > (as SIMPLE chair)
    >
    > Hi,
    >
    > We originally started work on draft-ietf-simple-chat back in 2007,  
    > with the idea that we could finish it quickly, and have something  
    > that works prior to completion of similar, but more general work in  
    > XCON.
    >
    > It's been two years now, so we clearly didn't finish it quickly, and  
    > it's been sitting without update or discussion since last spring.  
    > (Please don't take that as a complaint against the authors. I don't  
    > mean it that way--we're all busy here.) We are looking at how to get  
    > the draft moving again, but there's an important question we should  
    > address first:
    >
    > Is simple-chat still relevant? Should we take the effort to fix it,  
    > or should we shoot that milestone in the head?
    >
    > To recap, we WGLC'd simple-chat last April. There were non-trivial  
    > (but not necessarily earth-shattering) issues brought up in the  
    > feedback. That is, there's still at least a bit of work left to do  
    > on it.
    >
    > Perhaps Adam or Alan could comment on the status of the related work  
    > in XCON?
    >
    > Thanks!
    >
    > Ben.
    > _______________________________________________
    > 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
    --=_alternative 004C11D5C2257603_=-- From ag@ag-projects.com Thu Jul 30 09:57:19 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 249103A6CBC for ; Thu, 30 Jul 2009 09:57:19 -0700 (PDT) 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 FKEQLEgmGJYg for ; Thu, 30 Jul 2009 09:57:18 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id EDC713A6CAE for ; Thu, 30 Jul 2009 09:57:17 -0700 (PDT) Received: from dhcp-56ab.meeting.ietf.org ([130.129.86.171]) by node05.dns-hosting.info with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1MWYnp-0004rp-OF for simple@ietf.org; Thu, 30 Jul 2009 18:48:27 +0200 Message-Id: <1A449867-5015-45BB-997B-BEF881325487@ag-projects.com> From: Adrian Georgescu To: simple@ietf.org 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 v935.3) Date: Thu, 30 Jul 2009 18:57:12 +0200 References: X-Mailer: Apple Mail (2.935.3) X-SA-Exim-Connect-IP: 130.129.86.171 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: Re: [Simple] simple-chat status 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, 30 Jul 2009 16:57:19 -0000 There is at least one implementation for the draft in open source domain: http://chatserver.ag-projects.com/ It would take little effort to just go through with it as I do not see any need to make changes in this document. In the unfortunate case the draft is dropped I would much like to see its content not lost and if XCON is the resting place for its content then so be it. Adrian On Jul 30, 2009, at 3:56 PM, simple-request@ietf.org wrote: > From: > Ben Campbell > To: > Simple WG > Date: > 30/07/2009 03:45 PM > Subject: > Re: [Simple] simple-chat status > Sent by: > simple-bounces@ietf.org > > > > (As chair) > > The sense of the room in Stockholm was that we no longer needed the > simple-chat as it currently exists, but that we did need to make sure > we preserved the information in it that describes how a focus works > with MSRP and message/cpim, whether as a scaled down version of > simple- > chat or as an addition to the XCON documents. > > I'd like to make a consensus call on the list to confirm or deny that > approach. (I just saw Hisham's email--what do other's think?) > > Thanks! > > ben. > From victor.pascual.avila@gmail.com Thu Jul 30 13:51:11 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 29D9E3A6C67 for ; Thu, 30 Jul 2009 13:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.076, 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 uiqhjVAXlnhD for ; Thu, 30 Jul 2009 13:51:10 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id D8B9D3A6A02 for ; Thu, 30 Jul 2009 13:51:09 -0700 (PDT) Received: by ewy10 with SMTP id 10so1076731ewy.37 for ; Thu, 30 Jul 2009 13:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+RzAPfQpp1/NaLctvoDBpG7avx3QzJ+zwA04hp6hpRU=; b=fSvge4MH47sEClIhAIvXcwH/89TXpOosKf7zT1xxPFFP/iquLqOoqVkp39u4Wq/tja RE9e1LOLwKmrL8TW7OfDS1jjnRPyECiSt3Htl5jzsNDTjqcT2NKMwyRsONHeESUUbKXe 7npOCsZlDyQ5Z6rxpzoSNkMoyV072SZCqPycA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qg73p/PgE8RUJ1zTNj3kgm2lMVfMMLioG9G1glGUy6Ql1zt59qKKnrzsJ9ybl0rNCq lgunAbBW3W6tNJdmLt6+RmGc1LF5qhh/xhhoRjBRF6JFj9R7wKxaxbIiXJAIo8I6wQqS QwtpxRXIZnxzqV0V0ett5b04cJ7UxX1mXRMZ0= MIME-Version: 1.0 Received: by 10.216.6.198 with SMTP id 48mr345804wen.200.1248987068248; Thu, 30 Jul 2009 13:51:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2009 22:51:08 +0200 Message-ID: <618e24240907301351h35d8deacna97c6efd42faf99f@mail.gmail.com> From: Victor Pascual Avila To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] [OT] Ruby XCAPClient released 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, 30 Jul 2009 20:51:11 -0000 I=C3=B1aki, Thanks for sharing this-- I'll try it out. Cheers, -Victor On Thu, Jul 30, 2009 at 3:37 PM, I=C3=B1aki Baz Castillo wro= te: > Hi, if such announcement is not appropriate in this list please accept > my apologies. > > For those interested in building SIMPLE rich presence applications in > Ruby language I've released a GPLv3 library called XCAPClient: > > =C2=A0http://xcapclient.rubyforge.org/ > =C2=A0http://dev.sipdoc.net/projects/ruby-xcapclient/wiki/ > > > Ruby XCAPClient > -------------------------------------------------- > A XCAP client library written in Ruby language. > > XCAP (RFC 4825) is a protocol on top of HTTP which allows a client > (usually a VoIP/SIP device) to manipulate the contents of Presence > Information Data Format (PIDF) based presence documents. These > documents are stored in a server in XML format. > > Ruby xcapclient library implements the XCAP protocol in client side, > allowing the applications to get, store, modify and delete XML > documents in the server. > > > =3D=3D Features > > * Fetch, create/replace and delete a document. > * Fetch, create/replace and delete a document element (XML node). > * Fetch, create/replace and delete an element attribute. > * Full configurable parameters allowing customized fields for each > XCAP application, such auid, XML namespace, MIME-Type, scope (:user or > :global) and default document name ("index" if not set). > * Fetch the namespaces and prefixes of a document node as they are > used in the server. > * Manage of multiple documents per XCAP application. > * Fetch the XCAP server auids, extensions and namespaces ("xcap-caps" > application). > * SSL. > * Digest and Basic HTTP authentication. > * Raise custom Ruby exception for each HTTP error response. > -------------------------------------------------- > > > Regards. > > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --=20 Victor Pascual =C3=81vila From mary.barnes@nortel.com Fri Jul 31 02:01:26 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 7A3A53A6C9F for ; Fri, 31 Jul 2009 02:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tRbIirVND1dy for ; Fri, 31 Jul 2009 02:01:25 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1216C3A6CB3 for ; Fri, 31 Jul 2009 02:01:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6V8xG204431; Fri, 31 Jul 2009 08:59:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA11BD.6F318E8E" Date: Fri, 31 Jul 2009 04:01:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1BF5FE56@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] simple-chat status thread-index: AcoRNtcE142WCgNRRGSOLx94gYhq0AAed51i References: <1A449867-5015-45BB-997B-BEF881325487@ag-projects.com> From: "Mary Barnes" To: "Adrian Georgescu" , Subject: Re: [Simple] simple-chat status 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, 31 Jul 2009 09:01:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA11BD.6F318E8E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adrian, A few comments inline [MB]. Mary. -----Original Message----- From: simple-bounces@ietf.org on behalf of Adrian Georgescu Sent: Thu 7/30/2009 11:57 AM To: simple@ietf.org Subject: Re: [Simple] simple-chat status =20 There is at least one implementation for the draft in open source =20 domain: http://chatserver.ag-projects.com/ It would take little effort to just go through with it as I do not see =20 any need to make changes in this document.=20 [MB] Well, there are some changes that MUST be made before the document = is progressed, per the detailed review I did some time ago: http://www.ietf.org/mail-archive/web/simple/current/msg08371.html I honestly don't care if SIMPLE wants to put the cycles in to complete = the document. I agreed at the last meeting and thus did the document = review. I do have concerns in that It does burn WG cycles. And, since = it's a subset of the capabilities you get with XCON framework - another = concern is that it's wasted effort to implement an MSRP switch if the = more generic XCON framework - i.e., conference server & focus model is = not considered. =20 The primary protocol differences between implementing simple-chat vs = using the XCON framework for this functionality is the normative changes = to MSRP in the simple-chat document (e.g., NICKNAME) are naturally = handled with the CCMP protocol document - i.e., you don't need to change = MSRP if you implement this with CCMP. [/MB] In the unfortunate case the =20 draft is dropped I would much like to see its content not lost and if =20 XCON is the resting place for its content then so be it. Adrian On Jul 30, 2009, at 3:56 PM, simple-request@ietf.org wrote: > From: > Ben Campbell > To: > Simple WG > Date: > 30/07/2009 03:45 PM > Subject: > Re: [Simple] simple-chat status > Sent by: > simple-bounces@ietf.org > > > > (As chair) > > The sense of the room in Stockholm was that we no longer needed the > simple-chat as it currently exists, but that we did need to make sure > we preserved the information in it that describes how a focus works > with MSRP and message/cpim, whether as a scaled down version of =20 > simple- > chat or as an addition to the XCON documents. > > I'd like to make a consensus call on the list to confirm or deny that > approach. (I just saw Hisham's email--what do other's think?) > > Thanks! > > ben. > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01CA11BD.6F318E8E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] simple-chat status

    Adrian,

    A few comments inline [MB].

    Mary.


    -----Original Message-----
    From: simple-bounces@ietf.org on behalf of Adrian Georgescu
    Sent: Thu 7/30/2009 11:57 AM
    To: simple@ietf.org
    Subject: Re: [Simple] simple-chat status

    There is at least one implementation for the draft in open = source 
    domain:

    http://chatserver.ag-projects= .com/

    It would take little effort to just go through with it as I do not = see 
    any need to make changes in this document.
    [MB] Well, there are some changes that MUST be made before the document = is progressed, per the detailed review I did some time ago:
    http://www.ietf.org/mail-archive/web/simple/current/msg08371.html
    I honestly don't care if SIMPLE wants to put the cycles in to complete = the document.    I agreed at the last meeting and thus = did the document review. I do have concerns in that It does burn WG = cycles. And, since it's a subset of the capabilities you get with XCON = framework - another concern is that it's wasted effort to implement an = MSRP switch if the more generic XCON framework - i.e., conference server = & focus model is not considered. 

    The primary protocol differences between implementing simple-chat vs = using the XCON framework for this functionality is the normative changes = to MSRP in the simple-chat document (e.g., NICKNAME) are naturally = handled with the CCMP protocol document - i.e., you don't need to change = MSRP if you implement this with CCMP.  [/MB]

    In the unfortunate case the 
    draft is dropped I would much like to see its content not lost and = if 
    XCON is the resting place for its content then so be it.

    Adrian

    On Jul 30, 2009, at 3:56 PM, simple-request@ietf.org wrote:

    > From:
    > Ben Campbell <ben@nostrum.com>
    > To:
    > Simple WG <simple@ietf.org>
    > Date:
    > 30/07/2009 03:45 PM
    > Subject:
    > Re: [Simple] simple-chat status
    > Sent by:
    > simple-bounces@ietf.org
    >
    >
    >
    > (As chair)
    >
    > The sense of the room in Stockholm was that we no longer needed = the
    > simple-chat as it currently exists, but that we did need to make = sure
    > we preserved the information in it that describes how a focus = works
    > with MSRP and message/cpim, whether as a scaled down version = of 
    > simple-
    > chat or as an addition to the XCON documents.
    >
    > I'd like to make a consensus call on the list to confirm or deny = that
    > approach. (I just saw Hisham's email--what do other's think?)
    >
    > Thanks!
    >
    > ben.
    >

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

    ------_=_NextPart_001_01CA11BD.6F318E8E--