From simple-admin@ietf.org Wed Oct 1 00:10:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29898; Wed, 1 Oct 2003 00:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4YJS-0001YO-00; Wed, 01 Oct 2003 00:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4YJS-0001YJ-00; Wed, 01 Oct 2003 00:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YJO-0003AN-Pm; Wed, 01 Oct 2003 00:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Xov-0000qf-T1 for simple@optimus.ietf.org; Tue, 30 Sep 2003 23:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27489 for ; Tue, 30 Sep 2003 23:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Xot-0001EW-00 for simple@ietf.org; Tue, 30 Sep 2003 23:38:31 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Xot-0001EM-00 for simple@ietf.org; Tue, 30 Sep 2003 23:38:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h913btd03047; Tue, 30 Sep 2003 22:37:55 -0500 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1064979474.882.6.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt 2 Registration is Open Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 22:37:55 -0500 Content-Transfer-Encoding: 7bit Please register for the second SIMPLE interop event at http://simplet.jasomi.com/ The event will be December 3-5, 2003 in Banff, Alberta Canada and is being hosted by Jasomi Networks. There will be a $150 US registration fee for this event to cover the facility/network costs. Registration closes November 15 - please sign up as early as you can. If you have any questions about the event that aren't answered on the pages at http://simplet.jasomi.com/ or http://www.sipit.net/, please send them to me. Thanks, and see you in December! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 1 00:10:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29941 for ; Wed, 1 Oct 2003 00:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YJV-0003BE-La for simple-archive@odin.ietf.org; Wed, 01 Oct 2003 00:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h914A9lG012220 for simple-archive@odin.ietf.org; Wed, 1 Oct 2003 00:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YJV-0003B1-H6 for simple-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 00:10:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29898; Wed, 1 Oct 2003 00:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4YJS-0001YO-00; Wed, 01 Oct 2003 00:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4YJS-0001YJ-00; Wed, 01 Oct 2003 00:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YJO-0003AN-Pm; Wed, 01 Oct 2003 00:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Xov-0000qf-T1 for simple@optimus.ietf.org; Tue, 30 Sep 2003 23:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27489 for ; Tue, 30 Sep 2003 23:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Xot-0001EW-00 for simple@ietf.org; Tue, 30 Sep 2003 23:38:31 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Xot-0001EM-00 for simple@ietf.org; Tue, 30 Sep 2003 23:38:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h913btd03047; Tue, 30 Sep 2003 22:37:55 -0500 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1064979474.882.6.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt 2 Registration is Open Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 22:37:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please register for the second SIMPLE interop event at http://simplet.jasomi.com/ The event will be December 3-5, 2003 in Banff, Alberta Canada and is being hosted by Jasomi Networks. There will be a $150 US registration fee for this event to cover the facility/network costs. Registration closes November 15 - please sign up as early as you can. If you have any questions about the event that aren't answered on the pages at http://simplet.jasomi.com/ or http://www.sipit.net/, please send them to me. Thanks, and see you in December! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 01:33:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10278; Fri, 3 Oct 2003 01:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IYt-0003hx-00; Fri, 03 Oct 2003 01:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5IYs-0003hs-00; Fri, 03 Oct 2003 01:33:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IYn-0000ys-Tl; Fri, 03 Oct 2003 01:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IXs-0000vQ-Ks for simple@optimus.ietf.org; Fri, 03 Oct 2003 01:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10217 for ; Fri, 3 Oct 2003 01:31:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IXp-0003he-00 for simple@ietf.org; Fri, 03 Oct 2003 01:32:01 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A5IXo-0003hb-00 for simple@ietf.org; Fri, 03 Oct 2003 01:32:00 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h935W0lN008912 for ; Fri, 3 Oct 2003 07:32:00 +0200 (MEST) Received: from dossier.lmf.ericsson.se ([131.160.11.13]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YNS5Q6; Fri, 3 Oct 2003 07:32:59 +0200 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.21]) by dossier.lmf.ericsson.se (Postfix) with ESMTP id 3D26418A82 for ; Fri, 3 Oct 2003 08:32:00 +0300 (EEST) Message-ID: <3F7D09CF.8040409@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Discovery of an MSRP relay Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 08:31:59 +0300 Content-Transfer-Encoding: 7bit Hi: I would like to understand possible mechanisms to discover an MSRP relay in a network. Is this something that have been discussed before? When reading the MSRP draft, section 7.1.2, I found a discussion on the usage of DNS SRV when the MSRP client already knows the host name of the MSRP relay. Fair enough. But in most situations this requires either provisioning or some out of band configuration. In a roaming scenario, when the network changes oftenly, the address of the MSRP relay may change as well. So I believe there is a need for a discovery mechanism of the MSRP relay. If we compare with SIP, SIP uses DNS SRV records to solve this problem. The input to the DNS SRV query is a network name, and the answer is a host name. I was wondering if is this something that we can mimic in MSRP, as I believe the problem are pretty similar. Thanks a lot, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 01:33:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10309 for ; Fri, 3 Oct 2003 01:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IYx-00010Y-0T for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 01:33:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h935XAnQ003868 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 01:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IYw-00010J-TS for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 01:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10278; Fri, 3 Oct 2003 01:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IYt-0003hx-00; Fri, 03 Oct 2003 01:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5IYs-0003hs-00; Fri, 03 Oct 2003 01:33:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IYn-0000ys-Tl; Fri, 03 Oct 2003 01:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IXs-0000vQ-Ks for simple@optimus.ietf.org; Fri, 03 Oct 2003 01:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10217 for ; Fri, 3 Oct 2003 01:31:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IXp-0003he-00 for simple@ietf.org; Fri, 03 Oct 2003 01:32:01 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A5IXo-0003hb-00 for simple@ietf.org; Fri, 03 Oct 2003 01:32:00 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h935W0lN008912 for ; Fri, 3 Oct 2003 07:32:00 +0200 (MEST) Received: from dossier.lmf.ericsson.se ([131.160.11.13]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YNS5Q6; Fri, 3 Oct 2003 07:32:59 +0200 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.21]) by dossier.lmf.ericsson.se (Postfix) with ESMTP id 3D26418A82 for ; Fri, 3 Oct 2003 08:32:00 +0300 (EEST) Message-ID: <3F7D09CF.8040409@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Discovery of an MSRP relay Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 08:31:59 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: I would like to understand possible mechanisms to discover an MSRP relay in a network. Is this something that have been discussed before? When reading the MSRP draft, section 7.1.2, I found a discussion on the usage of DNS SRV when the MSRP client already knows the host name of the MSRP relay. Fair enough. But in most situations this requires either provisioning or some out of band configuration. In a roaming scenario, when the network changes oftenly, the address of the MSRP relay may change as well. So I believe there is a need for a discovery mechanism of the MSRP relay. If we compare with SIP, SIP uses DNS SRV records to solve this problem. The input to the DNS SRV query is a network name, and the answer is a host name. I was wondering if is this something that we can mimic in MSRP, as I believe the problem are pretty similar. Thanks a lot, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 02:16:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23136; Fri, 3 Oct 2003 02:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JEU-00044e-00; Fri, 03 Oct 2003 02:16:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JET-00044b-00; Fri, 03 Oct 2003 02:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JEQ-0003ll-Fe; Fri, 03 Oct 2003 02:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JDR-0003fI-4E for simple@optimus.ietf.org; Fri, 03 Oct 2003 02:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23023 for ; Fri, 3 Oct 2003 02:14:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JDM-000441-00 for simple@ietf.org; Fri, 03 Oct 2003 02:14:56 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A5JDM-00043G-00 for simple@ietf.org; Fri, 03 Oct 2003 02:14:56 -0400 Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h936EWUg025339; Fri, 3 Oct 2003 02:14:32 -0400 (EDT) Message-ID: <3F7CEF43.2050302@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Who can modify an XCAP usage XML document References: <2038BCC78B1AD641891A0D1AE133DBB701797128@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797128@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 02 Oct 2003 23:38:43 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Hi, > > In the current XCAP proposal (and I assume in the revised version > to be available soon), it is assumed that the creator of an XML > usage document is the sole member of a virtual access list. I.e. It > is only the creator who can modify the XML document. Right. The idea was that this was the default policy. If you wanted to have a different policy, you could define an xcap usage that, itself, specified what those policies are. The server would then need to understand that application usage. > > I believe this is a limitation and some changes need to be made to > such a problem. 2 solutions are possible > > 1. Require that each XCAP usage document define an ACL type of > list. One way of mandating this is by requiring XML documents in an > XCAP usage to have an element that carries URIs of resources that > have read/write access of a document. Careful - if you include the acl in the document then anyone who can write the document can also change the acl. The essence of what I am saying above is that you have the acl as a separate document, and the default policy for THAT document is that only the domain administrator and the user can change it. > The syntax of that element > can be left up to the usage document. For example, a usage document > can define something like: > > sip:*@nokia.com > > 2. Somehow generalise this in the base XCAP document using a HTTP > header or something in an multipart body. I'm not sure I follow what this means. It was my intention to try to address this, using the mechanism I mention above, in a subsequent document, which could (I think) be defined later. Can you give the specific usage you had in mind? Do you think it can't wait to be defined at a later time? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 02:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23202 for ; Fri, 3 Oct 2003 02:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JEb-0003nt-2N for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 02:16:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h936GCY0014615 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 02:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JEY-0003ne-K1 for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 02:16:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23136; Fri, 3 Oct 2003 02:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JEU-00044e-00; Fri, 03 Oct 2003 02:16:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JET-00044b-00; Fri, 03 Oct 2003 02:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JEQ-0003ll-Fe; Fri, 03 Oct 2003 02:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JDR-0003fI-4E for simple@optimus.ietf.org; Fri, 03 Oct 2003 02:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23023 for ; Fri, 3 Oct 2003 02:14:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JDM-000441-00 for simple@ietf.org; Fri, 03 Oct 2003 02:14:56 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A5JDM-00043G-00 for simple@ietf.org; Fri, 03 Oct 2003 02:14:56 -0400 Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h936EWUg025339; Fri, 3 Oct 2003 02:14:32 -0400 (EDT) Message-ID: <3F7CEF43.2050302@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Who can modify an XCAP usage XML document References: <2038BCC78B1AD641891A0D1AE133DBB701797128@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797128@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 02 Oct 2003 23:38:43 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Hi, > > In the current XCAP proposal (and I assume in the revised version > to be available soon), it is assumed that the creator of an XML > usage document is the sole member of a virtual access list. I.e. It > is only the creator who can modify the XML document. Right. The idea was that this was the default policy. If you wanted to have a different policy, you could define an xcap usage that, itself, specified what those policies are. The server would then need to understand that application usage. > > I believe this is a limitation and some changes need to be made to > such a problem. 2 solutions are possible > > 1. Require that each XCAP usage document define an ACL type of > list. One way of mandating this is by requiring XML documents in an > XCAP usage to have an element that carries URIs of resources that > have read/write access of a document. Careful - if you include the acl in the document then anyone who can write the document can also change the acl. The essence of what I am saying above is that you have the acl as a separate document, and the default policy for THAT document is that only the domain administrator and the user can change it. > The syntax of that element > can be left up to the usage document. For example, a usage document > can define something like: > > sip:*@nokia.com > > 2. Somehow generalise this in the base XCAP document using a HTTP > header or something in an multipart body. I'm not sure I follow what this means. It was my intention to try to address this, using the mechanism I mention above, in a subsequent document, which could (I think) be defined later. Can you give the specific usage you had in mind? Do you think it can't wait to be defined at a later time? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 02:27:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24012; Fri, 3 Oct 2003 02:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JQ4-0004EB-00; Fri, 03 Oct 2003 02:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JQ4-0004E8-00; Fri, 03 Oct 2003 02:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JQ1-0005b9-Bl; Fri, 03 Oct 2003 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JPj-0005YU-J0 for simple@optimus.ietf.org; Fri, 03 Oct 2003 02:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24000 for ; Fri, 3 Oct 2003 02:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JPf-0004Dx-00 for simple@ietf.org; Fri, 03 Oct 2003 02:27:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A5JPf-0004Dj-00 for simple@ietf.org; Fri, 03 Oct 2003 02:27:39 -0400 Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h936RDUg025373; Fri, 3 Oct 2003 02:27:14 -0400 (EDT) Message-ID: <3F7D16BC.9050000@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <3F7D09CF.8040409@ericsson.com> In-Reply-To: <3F7D09CF.8040409@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 02:27:08 -0400 Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Hi: > > I would like to understand possible mechanisms to discover an MSRP relay > in a network. Is this something that have been discussed before? > > When reading the MSRP draft, section 7.1.2, I found a discussion on the > usage of DNS SRV when the MSRP client already knows the host name of the > MSRP relay. Fair enough. But in most situations this requires either > provisioning or some out of band configuration. In a roaming scenario, > when the network changes oftenly, the address of the MSRP relay may > change as well. So I believe there is a need for a discovery mechanism > of the MSRP relay. Do you mean that it changes because you'll want to use one in the network you just roamed into? > > If we compare with SIP, SIP uses DNS SRV records to solve this problem. > The input to the DNS SRV query is a network name, and the answer is a > host name. I was wondering if is this something that we can mimic in > MSRP, as I believe the problem are pretty similar. The DNS SRV mechanism doesnt help you with local discovery of resources (i.e., the ones in the network I just roamed into). For that, we have been using a DHCP option code to return SIP servers. The analogy would therefore be to learn MSRP relays from DHCP too. However, I think a better model is to use DHCP to bootstrap a local access point (the SIP server) and from there learn everything else. The use of a relay might very well be something within the scope of a session policy that is enforced by the local network. In that case, the static policy mechanisms in the session policy draft: http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-policy-00.txt would work. The registration mechanism allows for the local network to convey static policies. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 02:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24032 for ; Fri, 3 Oct 2003 02:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JQ9-0005dc-A5 for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 02:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h936S9m1021673 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 02:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JQ8-0005dU-Vm for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 02:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24012; Fri, 3 Oct 2003 02:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JQ4-0004EB-00; Fri, 03 Oct 2003 02:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JQ4-0004E8-00; Fri, 03 Oct 2003 02:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JQ1-0005b9-Bl; Fri, 03 Oct 2003 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JPj-0005YU-J0 for simple@optimus.ietf.org; Fri, 03 Oct 2003 02:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24000 for ; Fri, 3 Oct 2003 02:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JPf-0004Dx-00 for simple@ietf.org; Fri, 03 Oct 2003 02:27:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A5JPf-0004Dj-00 for simple@ietf.org; Fri, 03 Oct 2003 02:27:39 -0400 Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h936RDUg025373; Fri, 3 Oct 2003 02:27:14 -0400 (EDT) Message-ID: <3F7D16BC.9050000@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <3F7D09CF.8040409@ericsson.com> In-Reply-To: <3F7D09CF.8040409@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 02:27:08 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Hi: > > I would like to understand possible mechanisms to discover an MSRP relay > in a network. Is this something that have been discussed before? > > When reading the MSRP draft, section 7.1.2, I found a discussion on the > usage of DNS SRV when the MSRP client already knows the host name of the > MSRP relay. Fair enough. But in most situations this requires either > provisioning or some out of band configuration. In a roaming scenario, > when the network changes oftenly, the address of the MSRP relay may > change as well. So I believe there is a need for a discovery mechanism > of the MSRP relay. Do you mean that it changes because you'll want to use one in the network you just roamed into? > > If we compare with SIP, SIP uses DNS SRV records to solve this problem. > The input to the DNS SRV query is a network name, and the answer is a > host name. I was wondering if is this something that we can mimic in > MSRP, as I believe the problem are pretty similar. The DNS SRV mechanism doesnt help you with local discovery of resources (i.e., the ones in the network I just roamed into). For that, we have been using a DHCP option code to return SIP servers. The analogy would therefore be to learn MSRP relays from DHCP too. However, I think a better model is to use DHCP to bootstrap a local access point (the SIP server) and from there learn everything else. The use of a relay might very well be something within the scope of a session policy that is enforced by the local network. In that case, the static policy mechanisms in the session policy draft: http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-policy-00.txt would work. The registration mechanism allows for the local network to convey static policies. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 02:44:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24433; Fri, 3 Oct 2003 02:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JgW-0004RO-00; Fri, 03 Oct 2003 02:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JgW-0004RL-00; Fri, 03 Oct 2003 02:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JgV-0006le-1C; Fri, 03 Oct 2003 02:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Jg6-0006jr-PJ for simple@optimus.ietf.org; Fri, 03 Oct 2003 02:44:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24428 for ; Fri, 3 Oct 2003 02:44:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Jg2-0004R4-00 for simple@ietf.org; Fri, 03 Oct 2003 02:44:34 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A5Jg2-0004QU-00 for simple@ietf.org; Fri, 03 Oct 2003 02:44:34 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h936iJN1025491; Fri, 3 Oct 2003 08:44:24 +0200 (MEST) Received: from dossier.lmf.ericsson.se ([131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YSPCHJ; Fri, 3 Oct 2003 08:47:03 +0200 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.21]) by dossier.lmf.ericsson.se (Postfix) with ESMTP id 1E47618A82; Fri, 3 Oct 2003 09:44:19 +0300 (EEST) Message-ID: <3F7D1AC2.4090700@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Jonathan Rosenberg Cc: simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <3F7D09CF.8040409@ericsson.com> <3F7D16BC.9050000@dynamicsoft.com> In-Reply-To: <3F7D16BC.9050000@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 09:44:18 +0300 Content-Transfer-Encoding: 7bit Inline. Jonathan Rosenberg wrote: > > > Miguel A. Garcia wrote: > >> Hi: >> >> I would like to understand possible mechanisms to discover an MSRP >> relay in a network. Is this something that have been discussed before? >> >> When reading the MSRP draft, section 7.1.2, I found a discussion on >> the usage of DNS SRV when the MSRP client already knows the host name >> of the MSRP relay. Fair enough. But in most situations this requires >> either provisioning or some out of band configuration. In a roaming >> scenario, when the network changes oftenly, the address of the MSRP >> relay may change as well. So I believe there is a need for a discovery >> mechanism of the MSRP relay. > > > Do you mean that it changes because you'll want to use one in the > network you just roamed into? I think both situations are possible: in one case, a client uses an MSRP relay in a roaming network. This could be the case of a hotel network. I believe DHCP will work fine here. In another case, an MSRP relay is provided in a home network, and that MSRP relay is used no matter whether the user is attached directly to such network or indirectly through other networks. In this case DHCP won't obviously solve the problem. > >> >> If we compare with SIP, SIP uses DNS SRV records to solve this >> problem. The input to the DNS SRV query is a network name, and the >> answer is a host name. I was wondering if is this something that we >> can mimic in MSRP, as I believe the problem are pretty similar. > > > The DNS SRV mechanism doesnt help you with local discovery of resources > (i.e., the ones in the network I just roamed into). If the client is aware of the network name, it will. > For that, we have > been using a DHCP option code to return SIP servers. The analogy would > therefore be to learn MSRP relays from DHCP too. However, I think a > better model is to use DHCP to bootstrap a local access point (the SIP > server) and from there learn everything else. The use of a relay might > very well be something within the scope of a session policy that is > enforced by the local network. In that case, the static policy > mechanisms in the session policy draft: > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-policy-00.txt Certainly this is another solution. It also fits into Gonzalo's draft on the same subject: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-policy-package-00.txt > > > would work. The registration mechanism allows for the local network to > convey static policies. > > -Jonathan R. > > > /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 02:45:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24452 for ; Fri, 3 Oct 2003 02:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Jgc-0006nX-Jk for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 02:45:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h936jAgl026114 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 02:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Jgb-0006n7-8f for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 02:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24433; Fri, 3 Oct 2003 02:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JgW-0004RO-00; Fri, 03 Oct 2003 02:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JgW-0004RL-00; Fri, 03 Oct 2003 02:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JgV-0006le-1C; Fri, 03 Oct 2003 02:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Jg6-0006jr-PJ for simple@optimus.ietf.org; Fri, 03 Oct 2003 02:44:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24428 for ; Fri, 3 Oct 2003 02:44:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Jg2-0004R4-00 for simple@ietf.org; Fri, 03 Oct 2003 02:44:34 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A5Jg2-0004QU-00 for simple@ietf.org; Fri, 03 Oct 2003 02:44:34 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h936iJN1025491; Fri, 3 Oct 2003 08:44:24 +0200 (MEST) Received: from dossier.lmf.ericsson.se ([131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YSPCHJ; Fri, 3 Oct 2003 08:47:03 +0200 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.21]) by dossier.lmf.ericsson.se (Postfix) with ESMTP id 1E47618A82; Fri, 3 Oct 2003 09:44:19 +0300 (EEST) Message-ID: <3F7D1AC2.4090700@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Jonathan Rosenberg Cc: simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <3F7D09CF.8040409@ericsson.com> <3F7D16BC.9050000@dynamicsoft.com> In-Reply-To: <3F7D16BC.9050000@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 09:44:18 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline. Jonathan Rosenberg wrote: > > > Miguel A. Garcia wrote: > >> Hi: >> >> I would like to understand possible mechanisms to discover an MSRP >> relay in a network. Is this something that have been discussed before? >> >> When reading the MSRP draft, section 7.1.2, I found a discussion on >> the usage of DNS SRV when the MSRP client already knows the host name >> of the MSRP relay. Fair enough. But in most situations this requires >> either provisioning or some out of band configuration. In a roaming >> scenario, when the network changes oftenly, the address of the MSRP >> relay may change as well. So I believe there is a need for a discovery >> mechanism of the MSRP relay. > > > Do you mean that it changes because you'll want to use one in the > network you just roamed into? I think both situations are possible: in one case, a client uses an MSRP relay in a roaming network. This could be the case of a hotel network. I believe DHCP will work fine here. In another case, an MSRP relay is provided in a home network, and that MSRP relay is used no matter whether the user is attached directly to such network or indirectly through other networks. In this case DHCP won't obviously solve the problem. > >> >> If we compare with SIP, SIP uses DNS SRV records to solve this >> problem. The input to the DNS SRV query is a network name, and the >> answer is a host name. I was wondering if is this something that we >> can mimic in MSRP, as I believe the problem are pretty similar. > > > The DNS SRV mechanism doesnt help you with local discovery of resources > (i.e., the ones in the network I just roamed into). If the client is aware of the network name, it will. > For that, we have > been using a DHCP option code to return SIP servers. The analogy would > therefore be to learn MSRP relays from DHCP too. However, I think a > better model is to use DHCP to bootstrap a local access point (the SIP > server) and from there learn everything else. The use of a relay might > very well be something within the scope of a session policy that is > enforced by the local network. In that case, the static policy > mechanisms in the session policy draft: > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-policy-00.txt Certainly this is another solution. It also fits into Gonzalo's draft on the same subject: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-policy-package-00.txt > > > would work. The registration mechanism allows for the local network to > convey static policies. > > -Jonathan R. > > > /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 06:07:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29221; Fri, 3 Oct 2003 06:07:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5MqV-0006GB-00; Fri, 03 Oct 2003 06:07:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5MqU-0006G8-00; Fri, 03 Oct 2003 06:07:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Mpx-0005yH-4s; Fri, 03 Oct 2003 06:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5MpK-0005xW-Oz for simple@optimus.ietf.org; Fri, 03 Oct 2003 06:06:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29193 for ; Fri, 3 Oct 2003 06:06:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5MpG-0006FK-00 for simple@ietf.org; Fri, 03 Oct 2003 06:06:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A5MpG-0006FH-00 for simple@ietf.org; Fri, 03 Oct 2003 06:06:18 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h93A6B613499 for ; Fri, 3 Oct 2003 13:06:11 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 Oct 2003 13:06:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 3 Oct 2003 13:06:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Who can modify an XCAP usage XML document Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179718D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Who can modify an XCAP usage XML document Thread-Index: AcOJdbVhENqUmIVoQ+CDdmWwXSVgTwAHwz5g To: Cc: X-OriginalArrivalTime: 03 Oct 2003 10:06:11.0466 (UTC) FILETIME=[F8D9C6A0:01C38995] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:06:10 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, October 03, 2003 6:39 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Who can modify an XCAP usage XML document >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Hi, > >=20 > > In the current XCAP proposal (and I assume in the revised version > > to be available soon), it is assumed that the creator of an XML > > usage document is the sole member of a virtual access list. I.e. It > > is only the creator who can modify the XML document. >=20 > Right. The idea was that this was the default policy. If you=20 > wanted to=20 > have a different policy, you could define an xcap usage that, itself,=20 > specified what those policies are. The server would then need to=20 > understand that application usage. Yes, this is something we talked about in the interim meeting. The issue = there was how to link the 2 application usages? >=20 >=20 > >=20 > > I believe this is a limitation and some changes need to be made to > > such a problem. 2 solutions are possible > >=20 > > 1. Require that each XCAP usage document define an ACL type of > > list. One way of mandating this is by requiring XML documents in an > > XCAP usage to have an element that carries URIs of resources that > > have read/write access of a document. >=20 > Careful - if you include the acl in the document then anyone who can=20 > write the document can also change the acl. The essence of what I am=20 > saying above is that you have the acl as a separate document, and the=20 > default policy for THAT document is that only the domain=20 > administrator=20 > and the user can change it. I agree this is a bad idea. >=20 >=20 > > The syntax of that element > > can be left up to the usage document. For example, a usage document > > can define something like: > >=20 > > sip:*@nokia.com > >=20 > > 2. Somehow generalise this in the base XCAP document using a HTTP > > header or something in an multipart body. >=20 > I'm not sure I follow what this means. I mean that the ACL can be carried in an HTTP header. But don't worry, I = think its another bad idea. What you describe above, IMO, in the right = solution. >=20 > It was my intention to try to address this, using the mechanism I=20 > mention above, in a subsequent document, which could (I think) be=20 > defined later. Can you give the specific usage you had in=20 > mind? Do you=20 > think it can't wait to be defined at a later time? It can certainly wait. The specific usage we had in mind is the CPCP = usage. Currently the privileges are carried in the XML document itself. = We recently concluded (you made the same conclusion) that its a bad = idea, so we ripped it out of the I-D ( -01 to be published soon). We also concluded that this type of thing can be done with a separate = usage document that can be specified at a later date. Thanks, Hisham >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 06:08:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29244 for ; Fri, 3 Oct 2003 06:08:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Mqa-0006Dr-8L for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 06:07:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93A7erC023920 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 06:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5MqZ-0006DJ-Np for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 06:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29221; Fri, 3 Oct 2003 06:07:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5MqV-0006GB-00; Fri, 03 Oct 2003 06:07:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5MqU-0006G8-00; Fri, 03 Oct 2003 06:07:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Mpx-0005yH-4s; Fri, 03 Oct 2003 06:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5MpK-0005xW-Oz for simple@optimus.ietf.org; Fri, 03 Oct 2003 06:06:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29193 for ; Fri, 3 Oct 2003 06:06:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5MpG-0006FK-00 for simple@ietf.org; Fri, 03 Oct 2003 06:06:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A5MpG-0006FH-00 for simple@ietf.org; Fri, 03 Oct 2003 06:06:18 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h93A6B613499 for ; Fri, 3 Oct 2003 13:06:11 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 Oct 2003 13:06:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 3 Oct 2003 13:06:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Who can modify an XCAP usage XML document Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179718D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Who can modify an XCAP usage XML document Thread-Index: AcOJdbVhENqUmIVoQ+CDdmWwXSVgTwAHwz5g To: Cc: X-OriginalArrivalTime: 03 Oct 2003 10:06:11.0466 (UTC) FILETIME=[F8D9C6A0:01C38995] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:06:10 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, October 03, 2003 6:39 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Who can modify an XCAP usage XML document >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Hi, > >=20 > > In the current XCAP proposal (and I assume in the revised version > > to be available soon), it is assumed that the creator of an XML > > usage document is the sole member of a virtual access list. I.e. It > > is only the creator who can modify the XML document. >=20 > Right. The idea was that this was the default policy. If you=20 > wanted to=20 > have a different policy, you could define an xcap usage that, itself,=20 > specified what those policies are. The server would then need to=20 > understand that application usage. Yes, this is something we talked about in the interim meeting. The issue = there was how to link the 2 application usages? >=20 >=20 > >=20 > > I believe this is a limitation and some changes need to be made to > > such a problem. 2 solutions are possible > >=20 > > 1. Require that each XCAP usage document define an ACL type of > > list. One way of mandating this is by requiring XML documents in an > > XCAP usage to have an element that carries URIs of resources that > > have read/write access of a document. >=20 > Careful - if you include the acl in the document then anyone who can=20 > write the document can also change the acl. The essence of what I am=20 > saying above is that you have the acl as a separate document, and the=20 > default policy for THAT document is that only the domain=20 > administrator=20 > and the user can change it. I agree this is a bad idea. >=20 >=20 > > The syntax of that element > > can be left up to the usage document. For example, a usage document > > can define something like: > >=20 > > sip:*@nokia.com > >=20 > > 2. Somehow generalise this in the base XCAP document using a HTTP > > header or something in an multipart body. >=20 > I'm not sure I follow what this means. I mean that the ACL can be carried in an HTTP header. But don't worry, I = think its another bad idea. What you describe above, IMO, in the right = solution. >=20 > It was my intention to try to address this, using the mechanism I=20 > mention above, in a subsequent document, which could (I think) be=20 > defined later. Can you give the specific usage you had in=20 > mind? Do you=20 > think it can't wait to be defined at a later time? It can certainly wait. The specific usage we had in mind is the CPCP = usage. Currently the privileges are carried in the XML document itself. = We recently concluded (you made the same conclusion) that its a bad = idea, so we ripped it out of the I-D ( -01 to be published soon). We also concluded that this type of thing can be done with a separate = usage document that can be specified at a later date. Thanks, Hisham >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 09:30:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06290; Fri, 3 Oct 2003 09:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q1P-0000np-00; Fri, 03 Oct 2003 09:31:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Q1P-0000nm-00; Fri, 03 Oct 2003 09:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q1N-0005gX-AF; Fri, 03 Oct 2003 09:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q0r-0005dc-P5 for simple@optimus.ietf.org; Fri, 03 Oct 2003 09:30:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06243 for ; Fri, 3 Oct 2003 09:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q0p-0000mv-00 for simple@ietf.org; Fri, 03 Oct 2003 09:30:27 -0400 Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q0o-0000m1-00 for simple@ietf.org; Fri, 03 Oct 2003 09:30:26 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.194]) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id h93DTog22013 for ; Fri, 3 Oct 2003 22:29:50 +0900 (JST) Received: from mailsv3.nec.co.jp (mailgate52.nec.co.jp [10.7.69.198]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id h93DTnf04446 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id h93DTnf20302 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.7/8.11.7) with ESMTP id h93DTnD26356 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Received: from splpe19 ([10.17.226.51]) by dns03.netlab.nec.co.jp (8.11.7/8.11.7) with SMTP id h93DTnO06825 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Message-ID: <007501c389b2$7c4470f0$33e2110a@lab5.netlab.nec.co.jp> From: "Naoko ITO" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Simple] Questions on XCAP Usage for Authorization Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 3 Oct 2003 22:30:17 +0900 Content-Transfer-Encoding: 7bit Hello, I have some questions on XCAP Usage for Authorization. The draft says, The overall authorization for a watcher is represented by the union of the permissions granted to that watcher. and In that case, the union of the permissions across those statements is applied to the subscription. Am I correctly understanding that the overall authorization is determined by simply putting together every permission related to a specific watcher? Then, some questions occur to me. - Is there any way to reject a watcher who is given permissions by other statements? ex) Give a permission to any user whose domain is "example.com" but Joe. - Is there a way to have a default policy which can be overridden by other statements? It seems possible to reject, or not to give a permission to all the watchers by default and add permisions to specific users only. But it does not seem possible to accept every user by default unless listed on a black list. - How to solve the conflicts between two or more permissions related to one watcher? I understand this is still under discussion, as it says, OPEN ISSUE: Another model is that you take permissions for the most specific match. I think union makes more sense in the model where the entries in the statement are permissions. but it'd be greatful if I can be provided any idea on this. Thank you in advance. Best Regards, ----- Naoko Ito / NEC _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 09:31:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06328 for ; Fri, 3 Oct 2003 09:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q1S-0005j8-9P for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 09:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93DV6ep022013 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 09:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q1S-0005iy-6a for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 09:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06290; Fri, 3 Oct 2003 09:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q1P-0000np-00; Fri, 03 Oct 2003 09:31:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Q1P-0000nm-00; Fri, 03 Oct 2003 09:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q1N-0005gX-AF; Fri, 03 Oct 2003 09:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q0r-0005dc-P5 for simple@optimus.ietf.org; Fri, 03 Oct 2003 09:30:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06243 for ; Fri, 3 Oct 2003 09:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q0p-0000mv-00 for simple@ietf.org; Fri, 03 Oct 2003 09:30:27 -0400 Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q0o-0000m1-00 for simple@ietf.org; Fri, 03 Oct 2003 09:30:26 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.194]) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id h93DTog22013 for ; Fri, 3 Oct 2003 22:29:50 +0900 (JST) Received: from mailsv3.nec.co.jp (mailgate52.nec.co.jp [10.7.69.198]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id h93DTnf04446 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id h93DTnf20302 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.7/8.11.7) with ESMTP id h93DTnD26356 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Received: from splpe19 ([10.17.226.51]) by dns03.netlab.nec.co.jp (8.11.7/8.11.7) with SMTP id h93DTnO06825 for ; Fri, 3 Oct 2003 22:29:49 +0900 (JST) Message-ID: <007501c389b2$7c4470f0$33e2110a@lab5.netlab.nec.co.jp> From: "Naoko ITO" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Simple] Questions on XCAP Usage for Authorization Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 3 Oct 2003 22:30:17 +0900 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I have some questions on XCAP Usage for Authorization. The draft says, The overall authorization for a watcher is represented by the union of the permissions granted to that watcher. and In that case, the union of the permissions across those statements is applied to the subscription. Am I correctly understanding that the overall authorization is determined by simply putting together every permission related to a specific watcher? Then, some questions occur to me. - Is there any way to reject a watcher who is given permissions by other statements? ex) Give a permission to any user whose domain is "example.com" but Joe. - Is there a way to have a default policy which can be overridden by other statements? It seems possible to reject, or not to give a permission to all the watchers by default and add permisions to specific users only. But it does not seem possible to accept every user by default unless listed on a black list. - How to solve the conflicts between two or more permissions related to one watcher? I understand this is still under discussion, as it says, OPEN ISSUE: Another model is that you take permissions for the most specific match. I think union makes more sense in the model where the entries in the statement are permissions. but it'd be greatful if I can be provided any idea on this. Thank you in advance. Best Regards, ----- Naoko Ito / NEC _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 3 16:37:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26558; Fri, 3 Oct 2003 16:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wfk-0006CW-00; Fri, 03 Oct 2003 16:37:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Wfk-0006CQ-00; Fri, 03 Oct 2003 16:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wfe-0002fp-8B; Fri, 03 Oct 2003 16:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WfW-0002ey-30 for simple@optimus.ietf.org; Fri, 03 Oct 2003 16:36:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26467; Fri, 3 Oct 2003 16:36:43 -0400 (EDT) Message-Id: <200310032036.QAA26467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presinfo-deliv-reg-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 16:36:43 -0400 --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 : Requirements for Efficient Delivery of Presence Information Author(s) : M. Lonnfors, et. al. Filename : draft-ietf-simple-presinfo-deliv-reg-01.txt Pages : 9 Date : 2003-10-3 A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. if presence information is delivered over radio links with high latency and low bandwidth. This memo presents requirements for a solution that can aid to reduce the impacts of these constrains and helps to increase efficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presinfo-deliv-reg-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presinfo-deliv-reg-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presinfo-deliv-reg-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-3164405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presinfo-deliv-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presinfo-deliv-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164405.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 3 16:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26658 for ; Fri, 3 Oct 2003 16:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wfn-0002iv-HF for simple-archive@odin.ietf.org; Fri, 03 Oct 2003 16:37:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KbBom010465 for simple-archive@odin.ietf.org; Fri, 3 Oct 2003 16:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wfn-0002ii-8w for simple-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:37:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26558; Fri, 3 Oct 2003 16:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wfk-0006CW-00; Fri, 03 Oct 2003 16:37:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Wfk-0006CQ-00; Fri, 03 Oct 2003 16:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wfe-0002fp-8B; Fri, 03 Oct 2003 16:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WfW-0002ey-30 for simple@optimus.ietf.org; Fri, 03 Oct 2003 16:36:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26467; Fri, 3 Oct 2003 16:36:43 -0400 (EDT) Message-Id: <200310032036.QAA26467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presinfo-deliv-reg-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 16:36:43 -0400 --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 : Requirements for Efficient Delivery of Presence Information Author(s) : M. Lonnfors, et. al. Filename : draft-ietf-simple-presinfo-deliv-reg-01.txt Pages : 9 Date : 2003-10-3 A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. if presence information is delivered over radio links with high latency and low bandwidth. This memo presents requirements for a solution that can aid to reduce the impacts of these constrains and helps to increase efficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presinfo-deliv-reg-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presinfo-deliv-reg-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presinfo-deliv-reg-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-3164405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presinfo-deliv-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presinfo-deliv-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164405.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 8 16:44:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08349; Wed, 8 Oct 2003 16:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LBA-0004B9-00; Wed, 08 Oct 2003 16:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7LB9-0004B2-00; Wed, 08 Oct 2003 16:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LB8-0000c2-Bu; Wed, 08 Oct 2003 16:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LAN-0000YM-DA for simple@optimus.ietf.org; Wed, 08 Oct 2003 16:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08330 for ; Wed, 8 Oct 2003 16:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LAL-0004Ae-00 for simple@ietf.org; Wed, 08 Oct 2003 16:44:13 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7LAK-0004AQ-00 for simple@ietf.org; Wed, 08 Oct 2003 16:44:12 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h98KhueY095949 for ; Wed, 8 Oct 2003 15:44:06 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F847701.3010600@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Administrative shutdown of relays Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 15:43:45 -0500 Content-Transfer-Encoding: 7bit I just realized that we had one more subject brought up in Vienna where we decided to "take it to the list". Which of course has not yet happened. The question was brought up that, in the previous version of MSRP where we refreshed state with BIND and VISIT, we had an implied mechanism by which a relay could shed load for shutdown. That is, is starts refusing refreshes until all sessions have expired. Since we have moved to a keep-alive approach rather than the refresh approach, this is not as clean. A couple of approaches come to mind: 1) Start refusing _any_ SEND requests, then assume all the sessions are gone when the timeout period expires. 2) Just close all TCP connections and let the endpoints deal with it. I find myself leaning toward 2, as 1 does not allow the endpoints to do anything useful on the session anyway. Thoughts? Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 8 16:45:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08365 for ; Wed, 8 Oct 2003 16:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LBD-0000dy-At for simple-archive@odin.ietf.org; Wed, 08 Oct 2003 16:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Kj79G002468 for simple-archive@odin.ietf.org; Wed, 8 Oct 2003 16:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LBD-0000dj-53 for simple-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08349; Wed, 8 Oct 2003 16:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LBA-0004B9-00; Wed, 08 Oct 2003 16:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7LB9-0004B2-00; Wed, 08 Oct 2003 16:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LB8-0000c2-Bu; Wed, 08 Oct 2003 16:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LAN-0000YM-DA for simple@optimus.ietf.org; Wed, 08 Oct 2003 16:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08330 for ; Wed, 8 Oct 2003 16:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LAL-0004Ae-00 for simple@ietf.org; Wed, 08 Oct 2003 16:44:13 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7LAK-0004AQ-00 for simple@ietf.org; Wed, 08 Oct 2003 16:44:12 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h98KhueY095949 for ; Wed, 8 Oct 2003 15:44:06 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F847701.3010600@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Administrative shutdown of relays Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 15:43:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I just realized that we had one more subject brought up in Vienna where we decided to "take it to the list". Which of course has not yet happened. The question was brought up that, in the previous version of MSRP where we refreshed state with BIND and VISIT, we had an implied mechanism by which a relay could shed load for shutdown. That is, is starts refusing refreshes until all sessions have expired. Since we have moved to a keep-alive approach rather than the refresh approach, this is not as clean. A couple of approaches come to mind: 1) Start refusing _any_ SEND requests, then assume all the sessions are gone when the timeout period expires. 2) Just close all TCP connections and let the endpoints deal with it. I find myself leaning toward 2, as 1 does not allow the endpoints to do anything useful on the session anyway. Thoughts? Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 8 17:56:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11077; Wed, 8 Oct 2003 17:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7MIt-00050A-00; Wed, 08 Oct 2003 17:57:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7MIt-000507-00; Wed, 08 Oct 2003 17:57:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MIm-0004vj-W2; Wed, 08 Oct 2003 17:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MIJ-0004ro-RV for simple@optimus.ietf.org; Wed, 08 Oct 2003 17:56:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11062 for ; Wed, 8 Oct 2003 17:56:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7MIH-0004zi-00 for simple@ietf.org; Wed, 08 Oct 2003 17:56:29 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7MIG-0004zf-00 for simple@ietf.org; Wed, 08 Oct 2003 17:56:28 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h98LtqeY002205; Wed, 8 Oct 2003 16:56:02 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8487DD.2030302@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Chris Boulton , Adam Roach , "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 16:55:41 -0500 Content-Transfer-Encoding: 7bit (Waking up a sleeping thread...) Okay, I will attempt to at least rationalize a number: The purpose of this timeout in the first place is to allow a hosting device to shed "stale" sessions. This is primarily important to relays, since they are likely to be hosting a whole bunch of sessions at any one time. The lower the timer value, the more efficiently they can do this. _But_, in the normal use case, the hosting endpoint will explicitly destroy the session. So "stale" sessions only really happen when the hosting endpoint screws up for some reason. Hopefully, we can assume this is at least uncommon, if not rare. Therefore the timer does not need to be particularly agressive. We currently have 2 votes for 12 minutes, which I find reasonable based on this rationale. I propose 10 minutes to the inevitable headscratching on why we chose 12 rather than 10 or 15. Of course, if someone would really like something like 12 minutes and 11.23 seconds, feel free to make the argument. This, however, brings up another issue. It occurred to me this afternoon, that while we do explicitly tell a hosting relay to destroy a session, we do not explicitly tell a _visiting_ relay. A visiting relay can infer this from the host closing the TCP connection. Is this good enough? Cullen Jennings wrote: > I think things between 1 and 60 sound pretty good but ... > > What we really need here is an argument why some number x is a good number. > > Cullen > > > On 9/11/03 11:08, "Chris Boulton" wrote: > > >>ok - If it must be his method I'll see Adams bid of 12 (and maybe even raise >>it ;-) . I think that it is a good compromise of traffic vs session clean up. >> >>Chris. >> >> >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Thu 11/09/2003 18:16 >>To: Adam Roach >>Cc: Miguel A. Garcia; simple@ietf.org >>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >> >> >> >>On reflection, I think I agree that a higher value than 1 minute makes >>sense. One use case I expect to see a lot for message sessions is the >>chat room, or text conference, where it will be common for one >>participant to receive a lot more than they send. >> >>Of course, at the same time, larger numbers reduce the ability of a >>relay to prune dead sessions. >> >>So I bid 5 minutes. >> >>Adam Roach wrote: >> >>>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >>> >>> >>> >>>>1) Do others agree with Miguel that we should make the inactivity >>>>timeout negotiable? >>> >>> >>>Having tried to go down this path several times, I want to >>>emphasize that I am very strongly opposed to any mechanism >>>for negotiation of this timeout. >>> >>> >>> >>>>2) If not, can anyone suggest a better way to choose the >>>>standard value? >>> >>> >>>Nope. One minute sounds good. One hour sounds good. I don't >>>think I'd want to go much outside that range. >>> >>>However, it sounds like there's some objection to something >>>as small as one minute, so we need to negotiate an arbitrary >>>value here on the list. I'll start the bidding at twelve >>>minutes. >>> >>>/a >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >> >>J) > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 8 17:57:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11094 for ; Wed, 8 Oct 2003 17:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MIx-0004wU-8K for simple-archive@odin.ietf.org; Wed, 08 Oct 2003 17:57:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98LvB5B018997 for simple-archive@odin.ietf.org; Wed, 8 Oct 2003 17:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MIx-0004wK-4K for simple-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 17:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11077; Wed, 8 Oct 2003 17:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7MIt-00050A-00; Wed, 08 Oct 2003 17:57:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7MIt-000507-00; Wed, 08 Oct 2003 17:57:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MIm-0004vj-W2; Wed, 08 Oct 2003 17:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7MIJ-0004ro-RV for simple@optimus.ietf.org; Wed, 08 Oct 2003 17:56:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11062 for ; Wed, 8 Oct 2003 17:56:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7MIH-0004zi-00 for simple@ietf.org; Wed, 08 Oct 2003 17:56:29 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7MIG-0004zf-00 for simple@ietf.org; Wed, 08 Oct 2003 17:56:28 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h98LtqeY002205; Wed, 8 Oct 2003 16:56:02 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8487DD.2030302@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Chris Boulton , Adam Roach , "Miguel A. Garcia" , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 16:55:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Waking up a sleeping thread...) Okay, I will attempt to at least rationalize a number: The purpose of this timeout in the first place is to allow a hosting device to shed "stale" sessions. This is primarily important to relays, since they are likely to be hosting a whole bunch of sessions at any one time. The lower the timer value, the more efficiently they can do this. _But_, in the normal use case, the hosting endpoint will explicitly destroy the session. So "stale" sessions only really happen when the hosting endpoint screws up for some reason. Hopefully, we can assume this is at least uncommon, if not rare. Therefore the timer does not need to be particularly agressive. We currently have 2 votes for 12 minutes, which I find reasonable based on this rationale. I propose 10 minutes to the inevitable headscratching on why we chose 12 rather than 10 or 15. Of course, if someone would really like something like 12 minutes and 11.23 seconds, feel free to make the argument. This, however, brings up another issue. It occurred to me this afternoon, that while we do explicitly tell a hosting relay to destroy a session, we do not explicitly tell a _visiting_ relay. A visiting relay can infer this from the host closing the TCP connection. Is this good enough? Cullen Jennings wrote: > I think things between 1 and 60 sound pretty good but ... > > What we really need here is an argument why some number x is a good number. > > Cullen > > > On 9/11/03 11:08, "Chris Boulton" wrote: > > >>ok - If it must be his method I'll see Adams bid of 12 (and maybe even raise >>it ;-) . I think that it is a good compromise of traffic vs session clean up. >> >>Chris. >> >> >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Thu 11/09/2003 18:16 >>To: Adam Roach >>Cc: Miguel A. Garcia; simple@ietf.org >>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >> >> >> >>On reflection, I think I agree that a higher value than 1 minute makes >>sense. One use case I expect to see a lot for message sessions is the >>chat room, or text conference, where it will be common for one >>participant to receive a lot more than they send. >> >>Of course, at the same time, larger numbers reduce the ability of a >>relay to prune dead sessions. >> >>So I bid 5 minutes. >> >>Adam Roach wrote: >> >>>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >>> >>> >>> >>>>1) Do others agree with Miguel that we should make the inactivity >>>>timeout negotiable? >>> >>> >>>Having tried to go down this path several times, I want to >>>emphasize that I am very strongly opposed to any mechanism >>>for negotiation of this timeout. >>> >>> >>> >>>>2) If not, can anyone suggest a better way to choose the >>>>standard value? >>> >>> >>>Nope. One minute sounds good. One hour sounds good. I don't >>>think I'd want to go much outside that range. >>> >>>However, it sounds like there's some objection to something >>>as small as one minute, so we need to negotiate an arbitrary >>>value here on the list. I'll start the bidding at twelve >>>minutes. >>> >>>/a >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >> >>J) > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 8 18:55:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13790; Wed, 8 Oct 2003 18:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NDu-0005XO-00; Wed, 08 Oct 2003 18:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NDu-0005XL-00; Wed, 08 Oct 2003 18:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NDt-0007re-KV; Wed, 08 Oct 2003 18:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ND6-0007r3-7n for simple@optimus.ietf.org; Wed, 08 Oct 2003 18:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13769 for ; Wed, 8 Oct 2003 18:55:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ND2-0005Wx-00 for simple@ietf.org; Wed, 08 Oct 2003 18:55:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7ND2-0005Wd-00 for simple@ietf.org; Wed, 08 Oct 2003 18:55:08 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h98MsVgk017227; Wed, 8 Oct 2003 18:54:31 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJPTM>; Wed, 8 Oct 2003 17:54:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E864E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Miguel A. Garcia'" , Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Discovery of an MSRP relay MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 17:54:24 -0500 Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > In another case, an MSRP relay is provided in a home network, > and that MSRP relay is used no matter whether the user is > attached directly to such network or indirectly through other > networks. In this case DHCP won't obviously solve the problem. For this case, I suggest we borrow a page from the well-understood, time-tested, universally deployed, and demonstrably workable mechanism that HTTP clients use to solve the problem of finding HTTP proxies. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 8 18:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13823 for ; Wed, 8 Oct 2003 18:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NDy-0007tZ-H1 for simple-archive@odin.ietf.org; Wed, 08 Oct 2003 18:56:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Mu6Ld030345 for simple-archive@odin.ietf.org; Wed, 8 Oct 2003 18:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NDy-0007tM-CS for simple-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 18:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13790; Wed, 8 Oct 2003 18:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NDu-0005XO-00; Wed, 08 Oct 2003 18:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NDu-0005XL-00; Wed, 08 Oct 2003 18:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NDt-0007re-KV; Wed, 08 Oct 2003 18:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ND6-0007r3-7n for simple@optimus.ietf.org; Wed, 08 Oct 2003 18:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13769 for ; Wed, 8 Oct 2003 18:55:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ND2-0005Wx-00 for simple@ietf.org; Wed, 08 Oct 2003 18:55:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7ND2-0005Wd-00 for simple@ietf.org; Wed, 08 Oct 2003 18:55:08 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h98MsVgk017227; Wed, 8 Oct 2003 18:54:31 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJPTM>; Wed, 8 Oct 2003 17:54:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E864E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Miguel A. Garcia'" , Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Discovery of an MSRP relay MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 17:54:24 -0500 Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > In another case, an MSRP relay is provided in a home network, > and that MSRP relay is used no matter whether the user is > attached directly to such network or indirectly through other > networks. In this case DHCP won't obviously solve the problem. For this case, I suggest we borrow a page from the well-understood, time-tested, universally deployed, and demonstrably workable mechanism that HTTP clients use to solve the problem of finding HTTP proxies. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 8 18:56:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13871; Wed, 8 Oct 2003 18:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NEr-0005YH-00; Wed, 08 Oct 2003 18:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NEq-0005YE-00; Wed, 08 Oct 2003 18:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NEr-00081V-Uc; Wed, 08 Oct 2003 18:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NEm-0007zD-ES for simple@optimus.ietf.org; Wed, 08 Oct 2003 18:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13864 for ; Wed, 8 Oct 2003 18:56:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NEj-0005Xx-00 for simple@ietf.org; Wed, 08 Oct 2003 18:56:53 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A7NEi-0005Xq-00 for simple@ietf.org; Wed, 08 Oct 2003 18:56:52 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h98Mu9O8002183; Wed, 8 Oct 2003 17:56:09 -0500 (CDT) Received: from ericsson.com (EFQ240013L1IJOG [164.48.154.79]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCA2JR; Wed, 8 Oct 2003 17:55:35 -0500 Message-ID: <3F8495F5.6080509@ericsson.com> X-Sybari-Trust: 5e30240a 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Cullen Jennings , Chris Boulton , Adam Roach , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F8487DD.2030302@dynamicsoft.com> In-Reply-To: <3F8487DD.2030302@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 01:55:49 +0300 Content-Transfer-Encoding: 7bit Hi Ben: I believe something on the order of 10 minutes sound better than the current 1 minute. So I wouldn't mind go for it. However, I have an alternative proposal. I would apologize if you already discuss it. Currently, as you mentioned previously, there are two timers: the pre-visit timer that controls the maximum time the MSRP relay will wait for a VISIT, and the session timer that controls the inactivity time after the BIND/VISIT procedure. I am not convinced that these two timers are different. What the MSRP relay is interested on is to get some activity from any of the endpoints so that the MSRP relay is aware that the session is still alive. Whether the data is a VISIT or SEND is irrelevant for the MSRP relay. So my proposal would be to simplify the timer management in the MSRP relay and go for a single timer, negotiatedin the Exp header (similar to the expiration timer of a registration in SIP). As a side effect, we could use the current Exp header, and send it to the visitor in a 200 OK for a VISIT. So the visitor is aware of the timer and (if not dead) will be able to refresh the session. I am pretty sure that this proposal will create a flare... but I feel provocative today ;-) Regards, Miguel Ben Campbell wrote: > (Waking up a sleeping thread...) > > Okay, I will attempt to at least rationalize a number: > > The purpose of this timeout in the first place is to allow a hosting > device to shed "stale" sessions. This is primarily important to relays, > since they are likely to be hosting a whole bunch of sessions at any one > time. The lower the timer value, the more efficiently they can do this. > > _But_, in the normal use case, the hosting endpoint will explicitly > destroy the session. So "stale" sessions only really happen when the > hosting endpoint screws up for some reason. Hopefully, we can assume > this is at least uncommon, if not rare. Therefore the timer does not > need to be particularly agressive. > > We currently have 2 votes for 12 minutes, which I find reasonable based > on this rationale. I propose 10 minutes to the inevitable headscratching > on why we chose 12 rather than 10 or 15. Of course, if someone would > really like something like 12 minutes and 11.23 seconds, feel free to > make the argument. > > This, however, brings up another issue. It occurred to me this > afternoon, that while we do explicitly tell a hosting relay to destroy a > session, we do not explicitly tell a _visiting_ relay. A visiting relay > can infer this from the host closing the TCP connection. Is this good > enough? > > > > > > > Cullen Jennings wrote: > >> I think things between 1 and 60 sound pretty good but ... >> >> What we really need here is an argument why some number x is a good >> number. >> >> Cullen >> >> >> On 9/11/03 11:08, "Chris Boulton" wrote: >> >> >>> ok - If it must be his method I'll see Adams bid of 12 (and maybe >>> even raise >>> it ;-) . I think that it is a good compromise of traffic vs session >>> clean up. >>> >>> Chris. >>> >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> Sent: Thu 11/09/2003 18:16 >>> To: Adam Roach Cc: Miguel A. Garcia; simple@ietf.org >>> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >>> >>> >>> >>> On reflection, I think I agree that a higher value than 1 minute makes >>> sense. One use case I expect to see a lot for message sessions is the >>> chat room, or text conference, where it will be common for one >>> participant to receive a lot more than they send. >>> >>> Of course, at the same time, larger numbers reduce the ability of a >>> relay to prune dead sessions. >>> >>> So I bid 5 minutes. >>> >>> Adam Roach wrote: >>> >>>> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >>>> >>>> >>>> >>>>> 1) Do others agree with Miguel that we should make the inactivity >>>>> timeout negotiable? >>>> >>>> >>>> >>>> Having tried to go down this path several times, I want to >>>> emphasize that I am very strongly opposed to any mechanism >>>> for negotiation of this timeout. >>>> >>>> >>>> >>>>> 2) If not, can anyone suggest a better way to choose the >>>>> standard value? >>>> >>>> >>>> >>>> Nope. One minute sounds good. One hour sounds good. I don't >>>> think I'd want to go much outside that range. >>>> >>>> However, it sounds like there's some objection to something >>>> as small as one minute, so we need to negotiate an arbitrary >>>> value here on the list. I'll start the bidding at twelve >>>> minutes. >>>> >>>> /a >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> J) >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 8 18:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13892 for ; Wed, 8 Oct 2003 18:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NEu-00084I-UK for simple-archive@odin.ietf.org; Wed, 08 Oct 2003 18:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Mv4Yv031008 for simple-archive@odin.ietf.org; Wed, 8 Oct 2003 18:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NEu-000843-Qg for simple-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 18:57:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13871; Wed, 8 Oct 2003 18:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NEr-0005YH-00; Wed, 08 Oct 2003 18:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NEq-0005YE-00; Wed, 08 Oct 2003 18:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NEr-00081V-Uc; Wed, 08 Oct 2003 18:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NEm-0007zD-ES for simple@optimus.ietf.org; Wed, 08 Oct 2003 18:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13864 for ; Wed, 8 Oct 2003 18:56:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NEj-0005Xx-00 for simple@ietf.org; Wed, 08 Oct 2003 18:56:53 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A7NEi-0005Xq-00 for simple@ietf.org; Wed, 08 Oct 2003 18:56:52 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h98Mu9O8002183; Wed, 8 Oct 2003 17:56:09 -0500 (CDT) Received: from ericsson.com (EFQ240013L1IJOG [164.48.154.79]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCA2JR; Wed, 8 Oct 2003 17:55:35 -0500 Message-ID: <3F8495F5.6080509@ericsson.com> X-Sybari-Trust: 5e30240a 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Cullen Jennings , Chris Boulton , Adam Roach , simple@ietf.org Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP References: <3F8487DD.2030302@dynamicsoft.com> In-Reply-To: <3F8487DD.2030302@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 01:55:49 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ben: I believe something on the order of 10 minutes sound better than the current 1 minute. So I wouldn't mind go for it. However, I have an alternative proposal. I would apologize if you already discuss it. Currently, as you mentioned previously, there are two timers: the pre-visit timer that controls the maximum time the MSRP relay will wait for a VISIT, and the session timer that controls the inactivity time after the BIND/VISIT procedure. I am not convinced that these two timers are different. What the MSRP relay is interested on is to get some activity from any of the endpoints so that the MSRP relay is aware that the session is still alive. Whether the data is a VISIT or SEND is irrelevant for the MSRP relay. So my proposal would be to simplify the timer management in the MSRP relay and go for a single timer, negotiatedin the Exp header (similar to the expiration timer of a registration in SIP). As a side effect, we could use the current Exp header, and send it to the visitor in a 200 OK for a VISIT. So the visitor is aware of the timer and (if not dead) will be able to refresh the session. I am pretty sure that this proposal will create a flare... but I feel provocative today ;-) Regards, Miguel Ben Campbell wrote: > (Waking up a sleeping thread...) > > Okay, I will attempt to at least rationalize a number: > > The purpose of this timeout in the first place is to allow a hosting > device to shed "stale" sessions. This is primarily important to relays, > since they are likely to be hosting a whole bunch of sessions at any one > time. The lower the timer value, the more efficiently they can do this. > > _But_, in the normal use case, the hosting endpoint will explicitly > destroy the session. So "stale" sessions only really happen when the > hosting endpoint screws up for some reason. Hopefully, we can assume > this is at least uncommon, if not rare. Therefore the timer does not > need to be particularly agressive. > > We currently have 2 votes for 12 minutes, which I find reasonable based > on this rationale. I propose 10 minutes to the inevitable headscratching > on why we chose 12 rather than 10 or 15. Of course, if someone would > really like something like 12 minutes and 11.23 seconds, feel free to > make the argument. > > This, however, brings up another issue. It occurred to me this > afternoon, that while we do explicitly tell a hosting relay to destroy a > session, we do not explicitly tell a _visiting_ relay. A visiting relay > can infer this from the host closing the TCP connection. Is this good > enough? > > > > > > > Cullen Jennings wrote: > >> I think things between 1 and 60 sound pretty good but ... >> >> What we really need here is an argument why some number x is a good >> number. >> >> Cullen >> >> >> On 9/11/03 11:08, "Chris Boulton" wrote: >> >> >>> ok - If it must be his method I'll see Adams bid of 12 (and maybe >>> even raise >>> it ;-) . I think that it is a good compromise of traffic vs session >>> clean up. >>> >>> Chris. >>> >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> Sent: Thu 11/09/2003 18:16 >>> To: Adam Roach Cc: Miguel A. Garcia; simple@ietf.org >>> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >>> >>> >>> >>> On reflection, I think I agree that a higher value than 1 minute makes >>> sense. One use case I expect to see a lot for message sessions is the >>> chat room, or text conference, where it will be common for one >>> participant to receive a lot more than they send. >>> >>> Of course, at the same time, larger numbers reduce the ability of a >>> relay to prune dead sessions. >>> >>> So I bid 5 minutes. >>> >>> Adam Roach wrote: >>> >>>> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >>>> >>>> >>>> >>>>> 1) Do others agree with Miguel that we should make the inactivity >>>>> timeout negotiable? >>>> >>>> >>>> >>>> Having tried to go down this path several times, I want to >>>> emphasize that I am very strongly opposed to any mechanism >>>> for negotiation of this timeout. >>>> >>>> >>>> >>>>> 2) If not, can anyone suggest a better way to choose the >>>>> standard value? >>>> >>>> >>>> >>>> Nope. One minute sounds good. One hour sounds good. I don't >>>> think I'd want to go much outside that range. >>>> >>>> However, it sounds like there's some objection to something >>>> as small as one minute, so we need to negotiate an arbitrary >>>> value here on the list. I'll start the bidding at twelve >>>> minutes. >>>> >>>> /a >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> J) >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 8 19:04:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14088; Wed, 8 Oct 2003 19:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NMa-0005cm-00; Wed, 08 Oct 2003 19:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NMa-0005cj-00; Wed, 08 Oct 2003 19:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NMb-0008I9-Kr; Wed, 08 Oct 2003 19:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NLo-0008Hc-F2 for simple@optimus.ietf.org; Wed, 08 Oct 2003 19:04:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14054 for ; Wed, 8 Oct 2003 19:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NLl-0005cJ-00 for simple@ietf.org; Wed, 08 Oct 2003 19:04:09 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A7NLk-0005c8-00 for simple@ietf.org; Wed, 08 Oct 2003 19:04:08 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h98N3VO8003274; Wed, 8 Oct 2003 18:03:31 -0500 (CDT) Received: from ericsson.com (EFQ240013L1IJOG [164.48.154.79]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCAJ2X; Wed, 8 Oct 2003 18:02:57 -0500 Message-ID: <3F8497B1.6050602@ericsson.com> X-Sybari-Trust: cf60efad 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <9BF66EBF6BEFD942915B4D4D45C051F3E864E1@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E864E1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 02:03:13 +0300 Content-Transfer-Encoding: 7bit Adam: Your proposal works if I am in my home network. But if I am roaming, the DHCP server will be located in the roaming network, and will be provisioned with information about the MSRP relay in the roaming network. If this is the case, fine, it will work, but if by policy, I have to use the MSRP provided in my home network, and I am roaming, it won't work. Further more, if the roaming network does not offer an MSRP relay service, but my home network does, I won't be able to discover the MSRP relay server. I am not sure, at this stage, which of the above cases would be the case for MSRP relays... I just want to be prepared with solutions that solve any of the possible requirements. /Miguel Adam Roach wrote: > Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > > >>In another case, an MSRP relay is provided in a home network, >>and that MSRP relay is used no matter whether the user is >>attached directly to such network or indirectly through other >>networks. In this case DHCP won't obviously solve the problem. > > > For this case, I suggest we borrow a page from the well-understood, > time-tested, universally deployed, and demonstrably workable > mechanism that HTTP clients use to solve the problem of finding > HTTP proxies. > > /a -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 8 19:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14117 for ; Wed, 8 Oct 2003 19:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NMe-0008Iw-SH for simple-archive@odin.ietf.org; Wed, 08 Oct 2003 19:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98N54ue031916 for simple-archive@odin.ietf.org; Wed, 8 Oct 2003 19:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NMe-0008Ih-Oi for simple-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 19:05:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14088; Wed, 8 Oct 2003 19:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NMa-0005cm-00; Wed, 08 Oct 2003 19:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NMa-0005cj-00; Wed, 08 Oct 2003 19:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NMb-0008I9-Kr; Wed, 08 Oct 2003 19:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NLo-0008Hc-F2 for simple@optimus.ietf.org; Wed, 08 Oct 2003 19:04:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14054 for ; Wed, 8 Oct 2003 19:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NLl-0005cJ-00 for simple@ietf.org; Wed, 08 Oct 2003 19:04:09 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A7NLk-0005c8-00 for simple@ietf.org; Wed, 08 Oct 2003 19:04:08 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h98N3VO8003274; Wed, 8 Oct 2003 18:03:31 -0500 (CDT) Received: from ericsson.com (EFQ240013L1IJOG [164.48.154.79]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCAJ2X; Wed, 8 Oct 2003 18:02:57 -0500 Message-ID: <3F8497B1.6050602@ericsson.com> X-Sybari-Trust: cf60efad 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <9BF66EBF6BEFD942915B4D4D45C051F3E864E1@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E864E1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 02:03:13 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam: Your proposal works if I am in my home network. But if I am roaming, the DHCP server will be located in the roaming network, and will be provisioned with information about the MSRP relay in the roaming network. If this is the case, fine, it will work, but if by policy, I have to use the MSRP provided in my home network, and I am roaming, it won't work. Further more, if the roaming network does not offer an MSRP relay service, but my home network does, I won't be able to discover the MSRP relay server. I am not sure, at this stage, which of the above cases would be the case for MSRP relays... I just want to be prepared with solutions that solve any of the possible requirements. /Miguel Adam Roach wrote: > Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > > >>In another case, an MSRP relay is provided in a home network, >>and that MSRP relay is used no matter whether the user is >>attached directly to such network or indirectly through other >>networks. In this case DHCP won't obviously solve the problem. > > > For this case, I suggest we borrow a page from the well-understood, > time-tested, universally deployed, and demonstrably workable > mechanism that HTTP clients use to solve the problem of finding > HTTP proxies. > > /a -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 09:14:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18496; Thu, 9 Oct 2003 09:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7acM-00068n-00; Thu, 09 Oct 2003 09:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7acM-00068k-00; Thu, 09 Oct 2003 09:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7acD-0002UD-1C; Thu, 09 Oct 2003 09:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7abN-0002TZ-CK for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18472 for ; Thu, 9 Oct 2003 09:13:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7abL-00067L-00 for simple@ietf.org; Thu, 09 Oct 2003 09:13:07 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7abK-00067H-00 for simple@ietf.org; Thu, 09 Oct 2003 09:13:06 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99DD2t14414 for ; Thu, 9 Oct 2003 16:13:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:13:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:13:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797215@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/w To: , X-OriginalArrivalTime: 09 Oct 2003 13:13:02.0422 (UTC) FILETIME=[11946760:01C38E67] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:13:01 +0300 Content-Transfer-Encoding: quoted-printable I vote for option 2. /Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, October 08, 2003 11:44 PM > To: simple@ietf.org > Subject: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > I just realized that we had one more subject brought up in=20 > Vienna where=20 > we decided to "take it to the list". Which of course has not=20 > yet happened. >=20 > The question was brought up that, in the previous version of=20 > MSRP where=20 > we refreshed state with BIND and VISIT, we had an implied=20 > mechanism by=20 > which a relay could shed load for shutdown. That is, is=20 > starts refusing=20 > refreshes until all sessions have expired. >=20 > Since we have moved to a keep-alive approach rather than the refresh=20 > approach, this is not as clean. A couple of approaches come to mind: >=20 > 1) Start refusing _any_ SEND requests, then assume all the=20 > sessions are=20 > gone when the timeout period expires. >=20 > 2) Just close all TCP connections and let the endpoints deal with it. >=20 > I find myself leaning toward 2, as 1 does not allow the=20 > endpoints to do=20 > anything useful on the session anyway. >=20 > Thoughts? >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 09:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18520 for ; Thu, 9 Oct 2003 09:14:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7acO-0002V5-SI for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 09:14:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99DEC1I009605 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 09:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7acO-0002Uq-P6 for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 09:14:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18496; Thu, 9 Oct 2003 09:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7acM-00068n-00; Thu, 09 Oct 2003 09:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7acM-00068k-00; Thu, 09 Oct 2003 09:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7acD-0002UD-1C; Thu, 09 Oct 2003 09:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7abN-0002TZ-CK for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18472 for ; Thu, 9 Oct 2003 09:13:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7abL-00067L-00 for simple@ietf.org; Thu, 09 Oct 2003 09:13:07 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7abK-00067H-00 for simple@ietf.org; Thu, 09 Oct 2003 09:13:06 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99DD2t14414 for ; Thu, 9 Oct 2003 16:13:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:13:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:13:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797215@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/w To: , X-OriginalArrivalTime: 09 Oct 2003 13:13:02.0422 (UTC) FILETIME=[11946760:01C38E67] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:13:01 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I vote for option 2. /Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, October 08, 2003 11:44 PM > To: simple@ietf.org > Subject: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > I just realized that we had one more subject brought up in=20 > Vienna where=20 > we decided to "take it to the list". Which of course has not=20 > yet happened. >=20 > The question was brought up that, in the previous version of=20 > MSRP where=20 > we refreshed state with BIND and VISIT, we had an implied=20 > mechanism by=20 > which a relay could shed load for shutdown. That is, is=20 > starts refusing=20 > refreshes until all sessions have expired. >=20 > Since we have moved to a keep-alive approach rather than the refresh=20 > approach, this is not as clean. A couple of approaches come to mind: >=20 > 1) Start refusing _any_ SEND requests, then assume all the=20 > sessions are=20 > gone when the timeout period expires. >=20 > 2) Just close all TCP connections and let the endpoints deal with it. >=20 > I find myself leaning toward 2, as 1 does not allow the=20 > endpoints to do=20 > anything useful on the session anyway. >=20 > Thoughts? >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 09:30:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18939; Thu, 9 Oct 2003 09:30:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ary-0006Km-00; Thu, 09 Oct 2003 09:30:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ary-0006KR-00; Thu, 09 Oct 2003 09:30:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ari-000378-PU; Thu, 09 Oct 2003 09:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ar4-00034N-74 for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:29:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18911 for ; Thu, 9 Oct 2003 09:29:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ar2-0006Ia-00 for simple@ietf.org; Thu, 09 Oct 2003 09:29:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7ar1-0006IX-00 for simple@ietf.org; Thu, 09 Oct 2003 09:29:19 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99DTIt04006 for ; Thu, 9 Oct 2003 16:29:18 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:29:18 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:29:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:29:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797216@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcON74ecj1y4xWQlRT2X9PZx9ZjgtgAeHDYQ To: , Cc: , , , X-OriginalArrivalTime: 09 Oct 2003 13:29:16.0576 (UTC) FILETIME=[56388200:01C38E69] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:29:16 +0300 Content-Transfer-Encoding: quoted-printable That's not a bad idea. The only drawback I see is that if, for some = currently unforeseeable reason, the policy at the Relay requires the 2 = timers to be different. Eg: the relay is willing to only wait a very = short time to receive the VISIT but is willing to wait the full 10 mins = for inactivity. Another related question: Can someone remind me why those timer values = are not left as Relay policy? If not, why isn't the pre-visit timer a = default value of x mins like we have for the inactivity timer? Regards, Hisham > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, October 09, 2003 1:56 AM > To: Ben Campbell > Cc: Cullen Jennings; Chris Boulton; Adam Roach; simple@ietf.org > Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >=20 >=20 > Hi Ben: >=20 > I believe something on the order of 10 minutes sound better than the=20 > current 1 minute. So I wouldn't mind go for it. >=20 > However, I have an alternative proposal. I would apologize if you=20 > already discuss it. >=20 > Currently, as you mentioned previously, there are two timers: the=20 > pre-visit timer that controls the maximum time the MSRP relay=20 > will wait=20 > for a VISIT, and the session timer that controls the inactivity time=20 > after the BIND/VISIT procedure. >=20 > I am not convinced that these two timers are different. What the MSRP=20 > relay is interested on is to get some activity from any of=20 > the endpoints=20 > so that the MSRP relay is aware that the session is still=20 > alive. Whether=20 > the data is a VISIT or SEND is irrelevant for the MSRP relay. So my=20 > proposal would be to simplify the timer management in the=20 > MSRP relay and=20 > go for a single timer, negotiatedin the Exp header (similar to the=20 > expiration timer of a registration in SIP). As a side effect,=20 > we could=20 > use the current Exp header, and send it to the visitor in a=20 > 200 OK for a=20 > VISIT. So the visitor is aware of the timer and (if not dead) will be=20 > able to refresh the session. >=20 > I am pretty sure that this proposal will create a flare... but I feel=20 > provocative today ;-) >=20 > Regards, >=20 > Miguel >=20 > Ben Campbell wrote: >=20 > > (Waking up a sleeping thread...) > >=20 > > Okay, I will attempt to at least rationalize a number: > >=20 > > The purpose of this timeout in the first place is to allow=20 > a hosting=20 > > device to shed "stale" sessions. This is primarily=20 > important to relays,=20 > > since they are likely to be hosting a whole bunch of=20 > sessions at any one=20 > > time. The lower the timer value, the more efficiently they=20 > can do this. > >=20 > > _But_, in the normal use case, the hosting endpoint will explicitly=20 > > destroy the session. So "stale" sessions only really happen=20 > when the=20 > > hosting endpoint screws up for some reason. Hopefully, we=20 > can assume=20 > > this is at least uncommon, if not rare. Therefore the timer=20 > does not=20 > > need to be particularly agressive. > >=20 > > We currently have 2 votes for 12 minutes, which I find=20 > reasonable based=20 > > on this rationale. I propose 10 minutes to the inevitable=20 > headscratching=20 > > on why we chose 12 rather than 10 or 15. Of course, if=20 > someone would=20 > > really like something like 12 minutes and 11.23 seconds,=20 > feel free to=20 > > make the argument. > >=20 > > This, however, brings up another issue. It occurred to me this=20 > > afternoon, that while we do explicitly tell a hosting relay=20 > to destroy a=20 > > session, we do not explicitly tell a _visiting_ relay. A=20 > visiting relay=20 > > can infer this from the host closing the TCP connection. Is=20 > this good=20 > > enough? > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Cullen Jennings wrote: > >=20 > >> I think things between 1 and 60 sound pretty good but ... > >> > >> What we really need here is an argument why some number x=20 > is a good=20 > >> number. > >> > >> Cullen > >> > >> > >> On 9/11/03 11:08, "Chris Boulton" wrote: > >> > >> > >>> ok - If it must be his method I'll see Adams bid of 12 (and maybe=20 > >>> even raise > >>> it ;-) . I think that it is a good compromise of traffic=20 > vs session=20 > >>> clean up. > >>> > >>> Chris. > >>> > >>> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: Thu 11/09/2003 18:16 > >>> To: Adam Roach Cc: Miguel A. Garcia; simple@ietf.org > >>> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > >>> > >>> > >>> > >>> On reflection, I think I agree that a higher value than 1=20 > minute makes > >>> sense. One use case I expect to see a lot for message=20 > sessions is the > >>> chat room, or text conference, where it will be common for one > >>> participant to receive a lot more than they send. > >>> > >>> Of course, at the same time, larger numbers reduce the=20 > ability of a > >>> relay to prune dead sessions. > >>> > >>> So I bid 5 minutes. > >>> > >>> Adam Roach wrote: > >>> > >>>> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >>>> > >>>> > >>>> > >>>>> 1) Do others agree with Miguel that we should make the=20 > inactivity > >>>>> timeout negotiable? > >>>> > >>>> > >>>> > >>>> Having tried to go down this path several times, I want to > >>>> emphasize that I am very strongly opposed to any mechanism > >>>> for negotiation of this timeout. > >>>> > >>>> > >>>> > >>>>> 2) If not, can anyone suggest a better way to choose the > >>>>> standard value? > >>>> > >>>> > >>>> > >>>> Nope. One minute sounds good. One hour sounds good. I don't > >>>> think I'd want to go much outside that range. > >>>> > >>>> However, it sounds like there's some objection to something > >>>> as small as one minute, so we need to negotiate an arbitrary > >>>> value here on the list. I'll start the bidding at twelve > >>>> minutes. > >>>> > >>>> /a > >>> > >>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>> J) > >> > >> > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 09:30:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19215 for ; Thu, 9 Oct 2003 09:30:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7as2-0003Il-Jm for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 09:30:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99DUMud012687 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 09:30:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7as1-0003GX-1y for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 09:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18939; Thu, 9 Oct 2003 09:30:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ary-0006Km-00; Thu, 09 Oct 2003 09:30:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ary-0006KR-00; Thu, 09 Oct 2003 09:30:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ari-000378-PU; Thu, 09 Oct 2003 09:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ar4-00034N-74 for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:29:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18911 for ; Thu, 9 Oct 2003 09:29:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ar2-0006Ia-00 for simple@ietf.org; Thu, 09 Oct 2003 09:29:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7ar1-0006IX-00 for simple@ietf.org; Thu, 09 Oct 2003 09:29:19 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99DTIt04006 for ; Thu, 9 Oct 2003 16:29:18 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:29:18 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:29:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:29:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797216@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Default 1 minute inactivity timer in MSRP Thread-Index: AcON74ecj1y4xWQlRT2X9PZx9ZjgtgAeHDYQ To: , Cc: , , , X-OriginalArrivalTime: 09 Oct 2003 13:29:16.0576 (UTC) FILETIME=[56388200:01C38E69] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:29:16 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable That's not a bad idea. The only drawback I see is that if, for some = currently unforeseeable reason, the policy at the Relay requires the 2 = timers to be different. Eg: the relay is willing to only wait a very = short time to receive the VISIT but is willing to wait the full 10 mins = for inactivity. Another related question: Can someone remind me why those timer values = are not left as Relay policy? If not, why isn't the pre-visit timer a = default value of x mins like we have for the inactivity timer? Regards, Hisham > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, October 09, 2003 1:56 AM > To: Ben Campbell > Cc: Cullen Jennings; Chris Boulton; Adam Roach; simple@ietf.org > Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP >=20 >=20 > Hi Ben: >=20 > I believe something on the order of 10 minutes sound better than the=20 > current 1 minute. So I wouldn't mind go for it. >=20 > However, I have an alternative proposal. I would apologize if you=20 > already discuss it. >=20 > Currently, as you mentioned previously, there are two timers: the=20 > pre-visit timer that controls the maximum time the MSRP relay=20 > will wait=20 > for a VISIT, and the session timer that controls the inactivity time=20 > after the BIND/VISIT procedure. >=20 > I am not convinced that these two timers are different. What the MSRP=20 > relay is interested on is to get some activity from any of=20 > the endpoints=20 > so that the MSRP relay is aware that the session is still=20 > alive. Whether=20 > the data is a VISIT or SEND is irrelevant for the MSRP relay. So my=20 > proposal would be to simplify the timer management in the=20 > MSRP relay and=20 > go for a single timer, negotiatedin the Exp header (similar to the=20 > expiration timer of a registration in SIP). As a side effect,=20 > we could=20 > use the current Exp header, and send it to the visitor in a=20 > 200 OK for a=20 > VISIT. So the visitor is aware of the timer and (if not dead) will be=20 > able to refresh the session. >=20 > I am pretty sure that this proposal will create a flare... but I feel=20 > provocative today ;-) >=20 > Regards, >=20 > Miguel >=20 > Ben Campbell wrote: >=20 > > (Waking up a sleeping thread...) > >=20 > > Okay, I will attempt to at least rationalize a number: > >=20 > > The purpose of this timeout in the first place is to allow=20 > a hosting=20 > > device to shed "stale" sessions. This is primarily=20 > important to relays,=20 > > since they are likely to be hosting a whole bunch of=20 > sessions at any one=20 > > time. The lower the timer value, the more efficiently they=20 > can do this. > >=20 > > _But_, in the normal use case, the hosting endpoint will explicitly=20 > > destroy the session. So "stale" sessions only really happen=20 > when the=20 > > hosting endpoint screws up for some reason. Hopefully, we=20 > can assume=20 > > this is at least uncommon, if not rare. Therefore the timer=20 > does not=20 > > need to be particularly agressive. > >=20 > > We currently have 2 votes for 12 minutes, which I find=20 > reasonable based=20 > > on this rationale. I propose 10 minutes to the inevitable=20 > headscratching=20 > > on why we chose 12 rather than 10 or 15. Of course, if=20 > someone would=20 > > really like something like 12 minutes and 11.23 seconds,=20 > feel free to=20 > > make the argument. > >=20 > > This, however, brings up another issue. It occurred to me this=20 > > afternoon, that while we do explicitly tell a hosting relay=20 > to destroy a=20 > > session, we do not explicitly tell a _visiting_ relay. A=20 > visiting relay=20 > > can infer this from the host closing the TCP connection. Is=20 > this good=20 > > enough? > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Cullen Jennings wrote: > >=20 > >> I think things between 1 and 60 sound pretty good but ... > >> > >> What we really need here is an argument why some number x=20 > is a good=20 > >> number. > >> > >> Cullen > >> > >> > >> On 9/11/03 11:08, "Chris Boulton" wrote: > >> > >> > >>> ok - If it must be his method I'll see Adams bid of 12 (and maybe=20 > >>> even raise > >>> it ;-) . I think that it is a good compromise of traffic=20 > vs session=20 > >>> clean up. > >>> > >>> Chris. > >>> > >>> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: Thu 11/09/2003 18:16 > >>> To: Adam Roach Cc: Miguel A. Garcia; simple@ietf.org > >>> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > >>> > >>> > >>> > >>> On reflection, I think I agree that a higher value than 1=20 > minute makes > >>> sense. One use case I expect to see a lot for message=20 > sessions is the > >>> chat room, or text conference, where it will be common for one > >>> participant to receive a lot more than they send. > >>> > >>> Of course, at the same time, larger numbers reduce the=20 > ability of a > >>> relay to prune dead sessions. > >>> > >>> So I bid 5 minutes. > >>> > >>> Adam Roach wrote: > >>> > >>>> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >>>> > >>>> > >>>> > >>>>> 1) Do others agree with Miguel that we should make the=20 > inactivity > >>>>> timeout negotiable? > >>>> > >>>> > >>>> > >>>> Having tried to go down this path several times, I want to > >>>> emphasize that I am very strongly opposed to any mechanism > >>>> for negotiation of this timeout. > >>>> > >>>> > >>>> > >>>>> 2) If not, can anyone suggest a better way to choose the > >>>>> standard value? > >>>> > >>>> > >>>> > >>>> Nope. One minute sounds good. One hour sounds good. I don't > >>>> think I'd want to go much outside that range. > >>>> > >>>> However, it sounds like there's some objection to something > >>>> as small as one minute, so we need to negotiate an arbitrary > >>>> value here on the list. I'll start the bidding at twelve > >>>> minutes. > >>>> > >>>> /a > >>> > >>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>> J) > >> > >> > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 09:31:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19275; Thu, 9 Oct 2003 09:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ath-0006Ly-00; Thu, 09 Oct 2003 09:32:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7atg-0006Lv-00; Thu, 09 Oct 2003 09:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7atc-0003RU-W8; Thu, 09 Oct 2003 09:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7at9-0003Ki-IH for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:31:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19266 for ; Thu, 9 Oct 2003 09:31:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7at7-0006Lk-00 for simple@ietf.org; Thu, 09 Oct 2003 09:31:29 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A7asY-0006I7-00 for simple@ietf.org; Thu, 09 Oct 2003 09:31:29 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 9 Oct 2003 14:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE0219B0D9@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naA= From: "Chris Boulton" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 14:25:58 +0100 Content-Transfer-Encoding: quoted-printable The only benefit I can see from using option 1 would be that an appropriate response/reason phrase to the SEND requests would allow a more graceful shutdown of sessions in an endpoint (The host of this session is terminating so I must dispose of the MSRP session) BUT I also see that option 2 keeps it SIMPLE ;-). Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 09 October 2003 14:13 >To: bcampbell@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >I vote for option 2. > >/Hisham > >> -----Original Message----- >> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> Sent: Wednesday, October 08, 2003 11:44 PM >> To: simple@ietf.org >> Subject: [Simple] MSRP: Administrative shutdown of relays >> >> >> I just realized that we had one more subject brought up in >> Vienna where >> we decided to "take it to the list". Which of course has not >> yet happened. >> >> The question was brought up that, in the previous version of >> MSRP where >> we refreshed state with BIND and VISIT, we had an implied >> mechanism by >> which a relay could shed load for shutdown. That is, is >> starts refusing >> refreshes until all sessions have expired. >> >> Since we have moved to a keep-alive approach rather than the refresh >> approach, this is not as clean. A couple of approaches come to mind: >> >> 1) Start refusing _any_ SEND requests, then assume all the >> sessions are >> gone when the timeout period expires. >> >> 2) Just close all TCP connections and let the endpoints deal with it. >> >> I find myself leaning toward 2, as 1 does not allow the >> endpoints to do >> anything useful on the session anyway. >> >> Thoughts? >> >> Ben. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 09:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19297 for ; Thu, 9 Oct 2003 09:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7atj-0003TQ-It for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 09:32:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99DW7ZO013346 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 09:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7atj-0003TB-FP for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 09:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19275; Thu, 9 Oct 2003 09:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ath-0006Ly-00; Thu, 09 Oct 2003 09:32:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7atg-0006Lv-00; Thu, 09 Oct 2003 09:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7atc-0003RU-W8; Thu, 09 Oct 2003 09:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7at9-0003Ki-IH for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:31:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19266 for ; Thu, 9 Oct 2003 09:31:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7at7-0006Lk-00 for simple@ietf.org; Thu, 09 Oct 2003 09:31:29 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A7asY-0006I7-00 for simple@ietf.org; Thu, 09 Oct 2003 09:31:29 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 9 Oct 2003 14:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE0219B0D9@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naA= From: "Chris Boulton" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 14:25:58 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The only benefit I can see from using option 1 would be that an appropriate response/reason phrase to the SEND requests would allow a more graceful shutdown of sessions in an endpoint (The host of this session is terminating so I must dispose of the MSRP session) BUT I also see that option 2 keeps it SIMPLE ;-). Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 09 October 2003 14:13 >To: bcampbell@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >I vote for option 2. > >/Hisham > >> -----Original Message----- >> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> Sent: Wednesday, October 08, 2003 11:44 PM >> To: simple@ietf.org >> Subject: [Simple] MSRP: Administrative shutdown of relays >> >> >> I just realized that we had one more subject brought up in >> Vienna where >> we decided to "take it to the list". Which of course has not >> yet happened. >> >> The question was brought up that, in the previous version of >> MSRP where >> we refreshed state with BIND and VISIT, we had an implied >> mechanism by >> which a relay could shed load for shutdown. That is, is >> starts refusing >> refreshes until all sessions have expired. >> >> Since we have moved to a keep-alive approach rather than the refresh >> approach, this is not as clean. A couple of approaches come to mind: >> >> 1) Start refusing _any_ SEND requests, then assume all the >> sessions are >> gone when the timeout period expires. >> >> 2) Just close all TCP connections and let the endpoints deal with it. >> >> I find myself leaning toward 2, as 1 does not allow the >> endpoints to do >> anything useful on the session anyway. >> >> Thoughts? >> >> Ben. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 09:34:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19389; Thu, 9 Oct 2003 09:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7awZ-0006O6-00; Thu, 09 Oct 2003 09:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7awZ-0006O3-00; Thu, 09 Oct 2003 09:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7awY-0003cW-Rz; Thu, 09 Oct 2003 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7awD-0003c5-KZ for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:34:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19379 for ; Thu, 9 Oct 2003 09:34:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7awB-0006Nq-00 for simple@ietf.org; Thu, 09 Oct 2003 09:34:39 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7awB-0006Nn-00 for simple@ietf.org; Thu, 09 Oct 2003 09:34:39 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99DYc609964 for ; Thu, 9 Oct 2003 16:34:38 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:34:37 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:34:36 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:34:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Discovery of an MSRP relay Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797217@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Discovery of an MSRP relay Thread-Index: AcON+xlpSZDVHJffSraoPthywZEPcAAbtBRg To: , Cc: , X-OriginalArrivalTime: 09 Oct 2003 13:34:36.0185 (UTC) FILETIME=[14B8F890:01C38E6A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:34:35 +0300 Content-Transfer-Encoding: quoted-printable How about UA configuration from SIPPING (or any other configuration = protocol)? /Hisham > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, October 09, 2003 2:03 AM > To: Adam Roach > Cc: Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] Discovery of an MSRP relay >=20 >=20 > Adam: >=20 > Your proposal works if I am in my home network. But if I am=20 > roaming, the=20 > DHCP server will be located in the roaming network, and will be=20 > provisioned with information about the MSRP relay in the roaming=20 > network. If this is the case, fine, it will work, but if by policy, I=20 > have to use the MSRP provided in my home network, and I am=20 > roaming, it=20 > won't work. Further more, if the roaming network does not=20 > offer an MSRP=20 > relay service, but my home network does, I won't be able to=20 > discover the=20 > MSRP relay server. >=20 > I am not sure, at this stage, which of the above cases would=20 > be the case=20 > for MSRP relays... I just want to be prepared with solutions=20 > that solve=20 > any of the possible requirements. >=20 > /Miguel >=20 > Adam Roach wrote: >=20 > > Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > >=20 > >=20 > >>In another case, an MSRP relay is provided in a home network,=20 > >>and that MSRP relay is used no matter whether the user is > >>attached directly to such network or indirectly through other > >>networks. In this case DHCP won't obviously solve the problem. > >=20 > >=20 > > For this case, I suggest we borrow a page from the well-understood, > > time-tested, universally deployed, and demonstrably workable > > mechanism that HTTP clients use to solve the problem of finding > > HTTP proxies. > >=20 > > /a >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 09:35:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19416 for ; Thu, 9 Oct 2003 09:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7awb-0003eS-NV for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 09:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99DZ5Rl014030 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 09:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7awb-0003eD-K8 for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 09:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19389; Thu, 9 Oct 2003 09:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7awZ-0006O6-00; Thu, 09 Oct 2003 09:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7awZ-0006O3-00; Thu, 09 Oct 2003 09:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7awY-0003cW-Rz; Thu, 09 Oct 2003 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7awD-0003c5-KZ for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:34:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19379 for ; Thu, 9 Oct 2003 09:34:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7awB-0006Nq-00 for simple@ietf.org; Thu, 09 Oct 2003 09:34:39 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7awB-0006Nn-00 for simple@ietf.org; Thu, 09 Oct 2003 09:34:39 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99DYc609964 for ; Thu, 9 Oct 2003 16:34:38 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:34:37 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:34:36 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:34:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Discovery of an MSRP relay Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797217@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Discovery of an MSRP relay Thread-Index: AcON+xlpSZDVHJffSraoPthywZEPcAAbtBRg To: , Cc: , X-OriginalArrivalTime: 09 Oct 2003 13:34:36.0185 (UTC) FILETIME=[14B8F890:01C38E6A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:34:35 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable How about UA configuration from SIPPING (or any other configuration = protocol)? /Hisham > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Thursday, October 09, 2003 2:03 AM > To: Adam Roach > Cc: Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] Discovery of an MSRP relay >=20 >=20 > Adam: >=20 > Your proposal works if I am in my home network. But if I am=20 > roaming, the=20 > DHCP server will be located in the roaming network, and will be=20 > provisioned with information about the MSRP relay in the roaming=20 > network. If this is the case, fine, it will work, but if by policy, I=20 > have to use the MSRP provided in my home network, and I am=20 > roaming, it=20 > won't work. Further more, if the roaming network does not=20 > offer an MSRP=20 > relay service, but my home network does, I won't be able to=20 > discover the=20 > MSRP relay server. >=20 > I am not sure, at this stage, which of the above cases would=20 > be the case=20 > for MSRP relays... I just want to be prepared with solutions=20 > that solve=20 > any of the possible requirements. >=20 > /Miguel >=20 > Adam Roach wrote: >=20 > > Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > >=20 > >=20 > >>In another case, an MSRP relay is provided in a home network,=20 > >>and that MSRP relay is used no matter whether the user is > >>attached directly to such network or indirectly through other > >>networks. In this case DHCP won't obviously solve the problem. > >=20 > >=20 > > For this case, I suggest we borrow a page from the well-understood, > > time-tested, universally deployed, and demonstrably workable > > mechanism that HTTP clients use to solve the problem of finding > > HTTP proxies. > >=20 > > /a >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 09:39:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19534; Thu, 9 Oct 2003 09:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7b1P-0006QV-00; Thu, 09 Oct 2003 09:40:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7b1P-0006QS-00; Thu, 09 Oct 2003 09:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7b1P-00048G-3A; Thu, 09 Oct 2003 09:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7b1D-00047f-8B for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:39:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19528 for ; Thu, 9 Oct 2003 09:39:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7b1B-0006QI-00 for simple@ietf.org; Thu, 09 Oct 2003 09:39:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7b1A-0006QF-00 for simple@ietf.org; Thu, 09 Oct 2003 09:39:48 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99Ddl615953 for ; Thu, 9 Oct 2003 16:39:47 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:38:56 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:38:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naAAAJOpQA== To: , , X-OriginalArrivalTime: 09 Oct 2003 13:38:56.0784 (UTC) FILETIME=[B00D3900:01C38E6A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:38:56 +0300 Content-Transfer-Encoding: quoted-printable Does a 400 response for a SEND request terminate the MSRP session? If = so, then option 1 (or a variant thereof) would be simple enough: A Relay = refuses all SEND requests, once it has done so for every connection, it = can assume all sessions are done and shut down. Of course option 2 is much SIMPLEr. /Hisham > -----Original Message----- > From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Thursday, October 09, 2003 4:26 PM > To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > The only benefit I can see from using option 1 would be that an > appropriate response/reason phrase to the SEND requests would allow a > more graceful shutdown of sessions in an endpoint (The host of this > session is terminating so I must dispose of the MSRP session)=20 > BUT I also > see that option 2 keeps it SIMPLE ;-). >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >Sent: 09 October 2003 14:13 > >To: bcampbell@dynamicsoft.com; simple@ietf.org > >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >I vote for option 2. > > > >/Hisham > > > >> -----Original Message----- > >> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >> Sent: Wednesday, October 08, 2003 11:44 PM > >> To: simple@ietf.org > >> Subject: [Simple] MSRP: Administrative shutdown of relays > >> > >> > >> I just realized that we had one more subject brought up in > >> Vienna where > >> we decided to "take it to the list". Which of course has not > >> yet happened. > >> > >> The question was brought up that, in the previous version of > >> MSRP where > >> we refreshed state with BIND and VISIT, we had an implied > >> mechanism by > >> which a relay could shed load for shutdown. That is, is > >> starts refusing > >> refreshes until all sessions have expired. > >> > >> Since we have moved to a keep-alive approach rather than=20 > the refresh > >> approach, this is not as clean. A couple of approaches=20 > come to mind: > >> > >> 1) Start refusing _any_ SEND requests, then assume all the > >> sessions are > >> gone when the timeout period expires. > >> > >> 2) Just close all TCP connections and let the endpoints=20 > deal with it. > >> > >> I find myself leaning toward 2, as 1 does not allow the > >> endpoints to do > >> anything useful on the session anyway. > >> > >> Thoughts? > >> > >> Ben. > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 09:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19561 for ; Thu, 9 Oct 2003 09:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7b1S-0004AP-K7 for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 09:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99De6Nw016003 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 09:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7b1R-00049y-Se for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 09:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19534; Thu, 9 Oct 2003 09:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7b1P-0006QV-00; Thu, 09 Oct 2003 09:40:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7b1P-0006QS-00; Thu, 09 Oct 2003 09:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7b1P-00048G-3A; Thu, 09 Oct 2003 09:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7b1D-00047f-8B for simple@optimus.ietf.org; Thu, 09 Oct 2003 09:39:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19528 for ; Thu, 9 Oct 2003 09:39:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7b1B-0006QI-00 for simple@ietf.org; Thu, 09 Oct 2003 09:39:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7b1A-0006QF-00 for simple@ietf.org; Thu, 09 Oct 2003 09:39:48 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99Ddl615953 for ; Thu, 9 Oct 2003 16:39:47 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 9 Oct 2003 16:38:56 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 16:38:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naAAAJOpQA== To: , , X-OriginalArrivalTime: 09 Oct 2003 13:38:56.0784 (UTC) FILETIME=[B00D3900:01C38E6A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 16:38:56 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does a 400 response for a SEND request terminate the MSRP session? If = so, then option 1 (or a variant thereof) would be simple enough: A Relay = refuses all SEND requests, once it has done so for every connection, it = can assume all sessions are done and shut down. Of course option 2 is much SIMPLEr. /Hisham > -----Original Message----- > From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Thursday, October 09, 2003 4:26 PM > To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > The only benefit I can see from using option 1 would be that an > appropriate response/reason phrase to the SEND requests would allow a > more graceful shutdown of sessions in an endpoint (The host of this > session is terminating so I must dispose of the MSRP session)=20 > BUT I also > see that option 2 keeps it SIMPLE ;-). >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >Sent: 09 October 2003 14:13 > >To: bcampbell@dynamicsoft.com; simple@ietf.org > >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >I vote for option 2. > > > >/Hisham > > > >> -----Original Message----- > >> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >> Sent: Wednesday, October 08, 2003 11:44 PM > >> To: simple@ietf.org > >> Subject: [Simple] MSRP: Administrative shutdown of relays > >> > >> > >> I just realized that we had one more subject brought up in > >> Vienna where > >> we decided to "take it to the list". Which of course has not > >> yet happened. > >> > >> The question was brought up that, in the previous version of > >> MSRP where > >> we refreshed state with BIND and VISIT, we had an implied > >> mechanism by > >> which a relay could shed load for shutdown. That is, is > >> starts refusing > >> refreshes until all sessions have expired. > >> > >> Since we have moved to a keep-alive approach rather than=20 > the refresh > >> approach, this is not as clean. A couple of approaches=20 > come to mind: > >> > >> 1) Start refusing _any_ SEND requests, then assume all the > >> sessions are > >> gone when the timeout period expires. > >> > >> 2) Just close all TCP connections and let the endpoints=20 > deal with it. > >> > >> I find myself leaning toward 2, as 1 does not allow the > >> endpoints to do > >> anything useful on the session anyway. > >> > >> Thoughts? > >> > >> Ben. > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 10:56:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23178; Thu, 9 Oct 2003 10:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cD1-0007Em-00; Thu, 09 Oct 2003 10:56:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7cD1-0007Ej-00; Thu, 09 Oct 2003 10:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cCw-0008Fl-0L; Thu, 09 Oct 2003 10:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cCX-0008FL-1j for simple@optimus.ietf.org; Thu, 09 Oct 2003 10:55:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23164 for ; Thu, 9 Oct 2003 10:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cCU-0007EV-00 for simple@ietf.org; Thu, 09 Oct 2003 10:55:34 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A7cCT-0007ES-00 for simple@ietf.org; Thu, 09 Oct 2003 10:55:33 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 9 Oct 2003 15:58:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE01E22DFA@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naAAAJOpQAACt5DA From: "Chris Boulton" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 15:54:57 +0100 Content-Transfer-Encoding: quoted-printable Both solutions seem OK - It's just a matter of weighing up the argument for simplicity vs End user experience. I think I am leaning towards user experience. Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 09 October 2003 14:39 >To: Chris Boulton; bcampbell@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >Does a 400 response for a SEND request terminate the MSRP session? If so, >then option 1 (or a variant thereof) would be simple enough: A Relay >refuses all SEND requests, once it has done so for every connection, it can >assume all sessions are done and shut down. > >Of course option 2 is much SIMPLEr. > >/Hisham > >> -----Original Message----- >> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >> Sent: Thursday, October 09, 2003 4:26 PM >> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >> simple@ietf.org >> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >> >> >> The only benefit I can see from using option 1 would be that an >> appropriate response/reason phrase to the SEND requests would allow a >> more graceful shutdown of sessions in an endpoint (The host of this >> session is terminating so I must dispose of the MSRP session) >> BUT I also >> see that option 2 keeps it SIMPLE ;-). >> >> Chris. >> >> >> >-----Original Message----- >> >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >> >Sent: 09 October 2003 14:13 >> >To: bcampbell@dynamicsoft.com; simple@ietf.org >> >Subject: RE: [Simple] MSRP: Administrative shutdown of relays >> > >> >I vote for option 2. >> > >> >/Hisham >> > >> >> -----Original Message----- >> >> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >> Sent: Wednesday, October 08, 2003 11:44 PM >> >> To: simple@ietf.org >> >> Subject: [Simple] MSRP: Administrative shutdown of relays >> >> >> >> >> >> I just realized that we had one more subject brought up in >> >> Vienna where >> >> we decided to "take it to the list". Which of course has not >> >> yet happened. >> >> >> >> The question was brought up that, in the previous version of >> >> MSRP where >> >> we refreshed state with BIND and VISIT, we had an implied >> >> mechanism by >> >> which a relay could shed load for shutdown. That is, is >> >> starts refusing >> >> refreshes until all sessions have expired. >> >> >> >> Since we have moved to a keep-alive approach rather than >> the refresh >> >> approach, this is not as clean. A couple of approaches >> come to mind: >> >> >> >> 1) Start refusing _any_ SEND requests, then assume all the >> >> sessions are >> >> gone when the timeout period expires. >> >> >> >> 2) Just close all TCP connections and let the endpoints >> deal with it. >> >> >> >> I find myself leaning toward 2, as 1 does not allow the >> >> endpoints to do >> >> anything useful on the session anyway. >> >> >> >> Thoughts? >> >> >> >> Ben. >> >> >> >> >> >> _______________________________________________ >> >> Simple mailing list >> >> Simple@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/simple >> >> >> > >> >_______________________________________________ >> >Simple mailing list >> >Simple@ietf.org >> >https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 10:56:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23212 for ; Thu, 9 Oct 2003 10:56:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cD5-0008GT-1F for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 10:56:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99EuBZu031768 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 10:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cD4-0008GJ-Rw for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23178; Thu, 9 Oct 2003 10:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cD1-0007Em-00; Thu, 09 Oct 2003 10:56:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7cD1-0007Ej-00; Thu, 09 Oct 2003 10:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cCw-0008Fl-0L; Thu, 09 Oct 2003 10:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cCX-0008FL-1j for simple@optimus.ietf.org; Thu, 09 Oct 2003 10:55:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23164 for ; Thu, 9 Oct 2003 10:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cCU-0007EV-00 for simple@ietf.org; Thu, 09 Oct 2003 10:55:34 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A7cCT-0007ES-00 for simple@ietf.org; Thu, 09 Oct 2003 10:55:33 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 9 Oct 2003 15:58:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE01E22DFA@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naAAAJOpQAACt5DA From: "Chris Boulton" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 15:54:57 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Both solutions seem OK - It's just a matter of weighing up the argument for simplicity vs End user experience. I think I am leaning towards user experience. Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 09 October 2003 14:39 >To: Chris Boulton; bcampbell@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >Does a 400 response for a SEND request terminate the MSRP session? If so, >then option 1 (or a variant thereof) would be simple enough: A Relay >refuses all SEND requests, once it has done so for every connection, it can >assume all sessions are done and shut down. > >Of course option 2 is much SIMPLEr. > >/Hisham > >> -----Original Message----- >> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >> Sent: Thursday, October 09, 2003 4:26 PM >> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >> simple@ietf.org >> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >> >> >> The only benefit I can see from using option 1 would be that an >> appropriate response/reason phrase to the SEND requests would allow a >> more graceful shutdown of sessions in an endpoint (The host of this >> session is terminating so I must dispose of the MSRP session) >> BUT I also >> see that option 2 keeps it SIMPLE ;-). >> >> Chris. >> >> >> >-----Original Message----- >> >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >> >Sent: 09 October 2003 14:13 >> >To: bcampbell@dynamicsoft.com; simple@ietf.org >> >Subject: RE: [Simple] MSRP: Administrative shutdown of relays >> > >> >I vote for option 2. >> > >> >/Hisham >> > >> >> -----Original Message----- >> >> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >> Sent: Wednesday, October 08, 2003 11:44 PM >> >> To: simple@ietf.org >> >> Subject: [Simple] MSRP: Administrative shutdown of relays >> >> >> >> >> >> I just realized that we had one more subject brought up in >> >> Vienna where >> >> we decided to "take it to the list". Which of course has not >> >> yet happened. >> >> >> >> The question was brought up that, in the previous version of >> >> MSRP where >> >> we refreshed state with BIND and VISIT, we had an implied >> >> mechanism by >> >> which a relay could shed load for shutdown. That is, is >> >> starts refusing >> >> refreshes until all sessions have expired. >> >> >> >> Since we have moved to a keep-alive approach rather than >> the refresh >> >> approach, this is not as clean. A couple of approaches >> come to mind: >> >> >> >> 1) Start refusing _any_ SEND requests, then assume all the >> >> sessions are >> >> gone when the timeout period expires. >> >> >> >> 2) Just close all TCP connections and let the endpoints >> deal with it. >> >> >> >> I find myself leaning toward 2, as 1 does not allow the >> >> endpoints to do >> >> anything useful on the session anyway. >> >> >> >> Thoughts? >> >> >> >> Ben. >> >> >> >> >> >> _______________________________________________ >> >> Simple mailing list >> >> Simple@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/simple >> >> >> > >> >_______________________________________________ >> >Simple mailing list >> >Simple@ietf.org >> >https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 11:11:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23763; Thu, 9 Oct 2003 11:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cSS-0007Pl-00; Thu, 09 Oct 2003 11:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7cSR-0007Pi-00; Thu, 09 Oct 2003 11:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cSP-0000rd-Rh; Thu, 09 Oct 2003 11:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cS8-0000oD-QE for simple@optimus.ietf.org; Thu, 09 Oct 2003 11:11:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23748 for ; Thu, 9 Oct 2003 11:11:34 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cS6-0007PJ-00 for simple@ietf.org; Thu, 09 Oct 2003 11:11:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7cS5-0007PG-00 for simple@ietf.org; Thu, 09 Oct 2003 11:11:41 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99FBP628738 for ; Thu, 9 Oct 2003 18:11:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 9 Oct 2003 18:11:22 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 18:11:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naAAAJOpQAABhInA To: Cc: X-OriginalArrivalTime: 09 Oct 2003 15:11:22.0277 (UTC) FILETIME=[996C4D50:01C38E77] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Internet-Draft on hard state presence publishing Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 18:11:22 +0300 Content-Transfer-Encoding: quoted-printable Hi all, The work on SIP PUBLISH for presence publication seems to be concluded = from SIMPLE WG point of view as the draft has been moved to SIP WG. SIP = PUBLISH allows PUA to publish "soft state" type of presence information = to the composer. However, publishing "hard state" information has been = deliberately left out of the scope of that particular mechanism: --- PUBLISH requests create soft state in the ESC. This state has a defined lifetime and will expire after a negotiated amount of time, requiring the publication to be refreshed by subsequent PUBLISH requests. Local policy at the compositor may in turn define hard state for a particular event package. That is, the steady-state of this event package in the absence of, or in addition to, soft state provided through the PUBLISH mechanism. Setting this hard state or configuring the composer policy is out of the scope of this specification. --- During the discussions related to presence publishing it was concluded = that also it would be good to have a solution for "hard state" = publishing. In the July IETF meeting the concensus seemed to be that an = XCAP application usage would be the correct and simple solution.=20 Myself and Eva Lepp=E4nen have put together an initial draft to address = this issue. You can find it here: http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usa= ge-00.txt The main idea is to use XCAP as the tool to manipulate the data, and the = data itself is in PIDF format exactly the same way as it would be if = published with SIP. The rules how a composer treats this data related to = data uploaded with SIP PUBLISH is outside the scope of the draft. (The = solution is specific to presence event, but using XCAP for publishing = hard state for any other event is certainly possible too, but defining a = generic specification for that did not seem to bring any additional = value.) There is one major open issue that should be addressed in our opinion. = We would like to be able to publish also external content, e.g. the = content referred by and elements. We could include = this in the draft by allowing the client to upload a file with HTTP/XCAP = and reference to them from the PIDF document. Some text should be added = how the composer is expected to treat this file, i.e. it should also be = able to change it to become INLINE content in NOTIFY, or place it under = a URI from which the watcher is able to fetch it (and change the URI in = PIDF accordingly), if the original URI is not accessible. We would like = to hear if people think that this problem should be in the scope of the = draft too, or whether you think this requires text in the standards at = all. In general we would like to get comments by the next IETF meeting and if = the draft seems OK, adopt is as a WG item. Regards, Markus=20 =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 11:12:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23815 for ; Thu, 9 Oct 2003 11:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cST-0000sY-Fy for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 11:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99FC5ce003372 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 11:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cST-0000sJ-Bu for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 11:12:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23763; Thu, 9 Oct 2003 11:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cSS-0007Pl-00; Thu, 09 Oct 2003 11:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7cSR-0007Pi-00; Thu, 09 Oct 2003 11:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cSP-0000rd-Rh; Thu, 09 Oct 2003 11:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cS8-0000oD-QE for simple@optimus.ietf.org; Thu, 09 Oct 2003 11:11:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23748 for ; Thu, 9 Oct 2003 11:11:34 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cS6-0007PJ-00 for simple@ietf.org; Thu, 09 Oct 2003 11:11:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7cS5-0007PG-00 for simple@ietf.org; Thu, 09 Oct 2003 11:11:41 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h99FBP628738 for ; Thu, 9 Oct 2003 18:11:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 9 Oct 2003 18:11:22 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 18:11:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcON3RwTLPJ8fB8MRlqX7P2ZxIC6GQAidx/wAAA6naAAAJOpQAABhInA To: Cc: X-OriginalArrivalTime: 09 Oct 2003 15:11:22.0277 (UTC) FILETIME=[996C4D50:01C38E77] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Internet-Draft on hard state presence publishing Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 18:11:22 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, The work on SIP PUBLISH for presence publication seems to be concluded = from SIMPLE WG point of view as the draft has been moved to SIP WG. SIP = PUBLISH allows PUA to publish "soft state" type of presence information = to the composer. However, publishing "hard state" information has been = deliberately left out of the scope of that particular mechanism: --- PUBLISH requests create soft state in the ESC. This state has a defined lifetime and will expire after a negotiated amount of time, requiring the publication to be refreshed by subsequent PUBLISH requests. Local policy at the compositor may in turn define hard state for a particular event package. That is, the steady-state of this event package in the absence of, or in addition to, soft state provided through the PUBLISH mechanism. Setting this hard state or configuring the composer policy is out of the scope of this specification. --- During the discussions related to presence publishing it was concluded = that also it would be good to have a solution for "hard state" = publishing. In the July IETF meeting the concensus seemed to be that an = XCAP application usage would be the correct and simple solution.=20 Myself and Eva Lepp=E4nen have put together an initial draft to address = this issue. You can find it here: http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usa= ge-00.txt The main idea is to use XCAP as the tool to manipulate the data, and the = data itself is in PIDF format exactly the same way as it would be if = published with SIP. The rules how a composer treats this data related to = data uploaded with SIP PUBLISH is outside the scope of the draft. (The = solution is specific to presence event, but using XCAP for publishing = hard state for any other event is certainly possible too, but defining a = generic specification for that did not seem to bring any additional = value.) There is one major open issue that should be addressed in our opinion. = We would like to be able to publish also external content, e.g. the = content referred by and elements. We could include = this in the draft by allowing the client to upload a file with HTTP/XCAP = and reference to them from the PIDF document. Some text should be added = how the composer is expected to treat this file, i.e. it should also be = able to change it to become INLINE content in NOTIFY, or place it under = a URI from which the watcher is able to fetch it (and change the URI in = PIDF accordingly), if the original URI is not accessible. We would like = to hear if people think that this problem should be in the scope of the = draft too, or whether you think this requires text in the standards at = all. In general we would like to get comments by the next IETF meeting and if = the draft seems OK, adopt is as a WG item. Regards, Markus=20 =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 11:50:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25168; Thu, 9 Oct 2003 11:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d3I-0000A4-00; Thu, 09 Oct 2003 11:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7d3I-0000A1-00; Thu, 09 Oct 2003 11:50:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d3C-0003GQ-0v; Thu, 09 Oct 2003 11:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d2q-0003Fx-FK for simple@optimus.ietf.org; Thu, 09 Oct 2003 11:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25153 for ; Thu, 9 Oct 2003 11:49:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d2p-00009e-00 for simple@ietf.org; Thu, 09 Oct 2003 11:49:39 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7d2o-00009P-00 for simple@ietf.org; Thu, 09 Oct 2003 11:49:38 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h99FmRgk020296; Thu, 9 Oct 2003 11:48:27 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJQJD>; Thu, 9 Oct 2003 10:48:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E864EB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Miguel A. Garcia'" , Ben Campbell Cc: Cullen Jennings , Chris Boulton , Adam Roach , simple@ietf.org Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 10:48:27 -0500 We went over the scenarios involving negotiated timers for several hours in Ottawa. With up to four interested parties involved (two endpoints, up to two relays), it's a nearly intractable problem. The consensus at that meeting (which, if I recall correctly, was validated on this mailing list) was that the additional complexity required to negotiate a timer (as opposed to using a fixed value) wasn't even close to being justified by the miniscule flexibility that it provides. In my experience, the most effective way to kill progress is to continually revisit decisions that have already been made. Please don't. /a > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Wednesday, October 08, 2003 17:56 > To: Ben Campbell > Cc: Cullen Jennings; Chris Boulton; Adam Roach; simple@ietf.org > Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > > > Hi Ben: > > I believe something on the order of 10 minutes sound better than the > current 1 minute. So I wouldn't mind go for it. > > However, I have an alternative proposal. I would apologize if you > already discuss it. > > Currently, as you mentioned previously, there are two timers: the > pre-visit timer that controls the maximum time the MSRP relay > will wait > for a VISIT, and the session timer that controls the inactivity time > after the BIND/VISIT procedure. > > I am not convinced that these two timers are different. What the MSRP > relay is interested on is to get some activity from any of > the endpoints > so that the MSRP relay is aware that the session is still > alive. Whether > the data is a VISIT or SEND is irrelevant for the MSRP relay. So my > proposal would be to simplify the timer management in the > MSRP relay and > go for a single timer, negotiatedin the Exp header (similar to the > expiration timer of a registration in SIP). As a side effect, > we could > use the current Exp header, and send it to the visitor in a > 200 OK for a > VISIT. So the visitor is aware of the timer and (if not dead) will be > able to refresh the session. > > I am pretty sure that this proposal will create a flare... but I feel > provocative today ;-) > > Regards, > > Miguel > > Ben Campbell wrote: > > > (Waking up a sleeping thread...) > > > > Okay, I will attempt to at least rationalize a number: > > > > The purpose of this timeout in the first place is to allow > a hosting > > device to shed "stale" sessions. This is primarily > important to relays, > > since they are likely to be hosting a whole bunch of > sessions at any one > > time. The lower the timer value, the more efficiently they > can do this. > > > > _But_, in the normal use case, the hosting endpoint will explicitly > > destroy the session. So "stale" sessions only really happen > when the > > hosting endpoint screws up for some reason. Hopefully, we > can assume > > this is at least uncommon, if not rare. Therefore the timer > does not > > need to be particularly agressive. > > > > We currently have 2 votes for 12 minutes, which I find > reasonable based > > on this rationale. I propose 10 minutes to the inevitable > headscratching > > on why we chose 12 rather than 10 or 15. Of course, if > someone would > > really like something like 12 minutes and 11.23 seconds, > feel free to > > make the argument. > > > > This, however, brings up another issue. It occurred to me this > > afternoon, that while we do explicitly tell a hosting relay > to destroy a > > session, we do not explicitly tell a _visiting_ relay. A > visiting relay > > can infer this from the host closing the TCP connection. Is > this good > > enough? > > > > > > > > > > > > > > Cullen Jennings wrote: > > > >> I think things between 1 and 60 sound pretty good but ... > >> > >> What we really need here is an argument why some number x > is a good > >> number. > >> > >> Cullen > >> > >> > >> On 9/11/03 11:08, "Chris Boulton" wrote: > >> > >> > >>> ok - If it must be his method I'll see Adams bid of 12 (and maybe > >>> even raise > >>> it ;-) . I think that it is a good compromise of traffic > vs session > >>> clean up. > >>> > >>> Chris. > >>> > >>> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: Thu 11/09/2003 18:16 > >>> To: Adam Roach Cc: Miguel A. Garcia; simple@ietf.org > >>> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > >>> > >>> > >>> > >>> On reflection, I think I agree that a higher value than 1 > minute makes > >>> sense. One use case I expect to see a lot for message > sessions is the > >>> chat room, or text conference, where it will be common for one > >>> participant to receive a lot more than they send. > >>> > >>> Of course, at the same time, larger numbers reduce the > ability of a > >>> relay to prune dead sessions. > >>> > >>> So I bid 5 minutes. > >>> > >>> Adam Roach wrote: > >>> > >>>> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >>>> > >>>> > >>>> > >>>>> 1) Do others agree with Miguel that we should make the > inactivity > >>>>> timeout negotiable? > >>>> > >>>> > >>>> > >>>> Having tried to go down this path several times, I want to > >>>> emphasize that I am very strongly opposed to any mechanism > >>>> for negotiation of this timeout. > >>>> > >>>> > >>>> > >>>>> 2) If not, can anyone suggest a better way to choose the > >>>>> standard value? > >>>> > >>>> > >>>> > >>>> Nope. One minute sounds good. One hour sounds good. I don't > >>>> think I'd want to go much outside that range. > >>>> > >>>> However, it sounds like there's some objection to something > >>>> as small as one minute, so we need to negotiate an arbitrary > >>>> value here on the list. I'll start the bidding at twelve > >>>> minutes. > >>>> > >>>> /a > >>> > >>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>> J) > >> > >> > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > > > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 11:50:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25201 for ; Thu, 9 Oct 2003 11:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d3K-0003IK-Ge for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 11:50:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99FoAuT012658 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 11:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d3K-0003I5-Cu for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 11:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25168; Thu, 9 Oct 2003 11:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d3I-0000A4-00; Thu, 09 Oct 2003 11:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7d3I-0000A1-00; Thu, 09 Oct 2003 11:50:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d3C-0003GQ-0v; Thu, 09 Oct 2003 11:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d2q-0003Fx-FK for simple@optimus.ietf.org; Thu, 09 Oct 2003 11:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25153 for ; Thu, 9 Oct 2003 11:49:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d2p-00009e-00 for simple@ietf.org; Thu, 09 Oct 2003 11:49:39 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7d2o-00009P-00 for simple@ietf.org; Thu, 09 Oct 2003 11:49:38 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h99FmRgk020296; Thu, 9 Oct 2003 11:48:27 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJQJD>; Thu, 9 Oct 2003 10:48:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E864EB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Miguel A. Garcia'" , Ben Campbell Cc: Cullen Jennings , Chris Boulton , Adam Roach , simple@ietf.org Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 10:48:27 -0500 We went over the scenarios involving negotiated timers for several hours in Ottawa. With up to four interested parties involved (two endpoints, up to two relays), it's a nearly intractable problem. The consensus at that meeting (which, if I recall correctly, was validated on this mailing list) was that the additional complexity required to negotiate a timer (as opposed to using a fixed value) wasn't even close to being justified by the miniscule flexibility that it provides. In my experience, the most effective way to kill progress is to continually revisit decisions that have already been made. Please don't. /a > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Wednesday, October 08, 2003 17:56 > To: Ben Campbell > Cc: Cullen Jennings; Chris Boulton; Adam Roach; simple@ietf.org > Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > > > Hi Ben: > > I believe something on the order of 10 minutes sound better than the > current 1 minute. So I wouldn't mind go for it. > > However, I have an alternative proposal. I would apologize if you > already discuss it. > > Currently, as you mentioned previously, there are two timers: the > pre-visit timer that controls the maximum time the MSRP relay > will wait > for a VISIT, and the session timer that controls the inactivity time > after the BIND/VISIT procedure. > > I am not convinced that these two timers are different. What the MSRP > relay is interested on is to get some activity from any of > the endpoints > so that the MSRP relay is aware that the session is still > alive. Whether > the data is a VISIT or SEND is irrelevant for the MSRP relay. So my > proposal would be to simplify the timer management in the > MSRP relay and > go for a single timer, negotiatedin the Exp header (similar to the > expiration timer of a registration in SIP). As a side effect, > we could > use the current Exp header, and send it to the visitor in a > 200 OK for a > VISIT. So the visitor is aware of the timer and (if not dead) will be > able to refresh the session. > > I am pretty sure that this proposal will create a flare... but I feel > provocative today ;-) > > Regards, > > Miguel > > Ben Campbell wrote: > > > (Waking up a sleeping thread...) > > > > Okay, I will attempt to at least rationalize a number: > > > > The purpose of this timeout in the first place is to allow > a hosting > > device to shed "stale" sessions. This is primarily > important to relays, > > since they are likely to be hosting a whole bunch of > sessions at any one > > time. The lower the timer value, the more efficiently they > can do this. > > > > _But_, in the normal use case, the hosting endpoint will explicitly > > destroy the session. So "stale" sessions only really happen > when the > > hosting endpoint screws up for some reason. Hopefully, we > can assume > > this is at least uncommon, if not rare. Therefore the timer > does not > > need to be particularly agressive. > > > > We currently have 2 votes for 12 minutes, which I find > reasonable based > > on this rationale. I propose 10 minutes to the inevitable > headscratching > > on why we chose 12 rather than 10 or 15. Of course, if > someone would > > really like something like 12 minutes and 11.23 seconds, > feel free to > > make the argument. > > > > This, however, brings up another issue. It occurred to me this > > afternoon, that while we do explicitly tell a hosting relay > to destroy a > > session, we do not explicitly tell a _visiting_ relay. A > visiting relay > > can infer this from the host closing the TCP connection. Is > this good > > enough? > > > > > > > > > > > > > > Cullen Jennings wrote: > > > >> I think things between 1 and 60 sound pretty good but ... > >> > >> What we really need here is an argument why some number x > is a good > >> number. > >> > >> Cullen > >> > >> > >> On 9/11/03 11:08, "Chris Boulton" wrote: > >> > >> > >>> ok - If it must be his method I'll see Adams bid of 12 (and maybe > >>> even raise > >>> it ;-) . I think that it is a good compromise of traffic > vs session > >>> clean up. > >>> > >>> Chris. > >>> > >>> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: Thu 11/09/2003 18:16 > >>> To: Adam Roach Cc: Miguel A. Garcia; simple@ietf.org > >>> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP > >>> > >>> > >>> > >>> On reflection, I think I agree that a higher value than 1 > minute makes > >>> sense. One use case I expect to see a lot for message > sessions is the > >>> chat room, or text conference, where it will be common for one > >>> participant to receive a lot more than they send. > >>> > >>> Of course, at the same time, larger numbers reduce the > ability of a > >>> relay to prune dead sessions. > >>> > >>> So I bid 5 minutes. > >>> > >>> Adam Roach wrote: > >>> > >>>> Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >>>> > >>>> > >>>> > >>>>> 1) Do others agree with Miguel that we should make the > inactivity > >>>>> timeout negotiable? > >>>> > >>>> > >>>> > >>>> Having tried to go down this path several times, I want to > >>>> emphasize that I am very strongly opposed to any mechanism > >>>> for negotiation of this timeout. > >>>> > >>>> > >>>> > >>>>> 2) If not, can anyone suggest a better way to choose the > >>>>> standard value? > >>>> > >>>> > >>>> > >>>> Nope. One minute sounds good. One hour sounds good. I don't > >>>> think I'd want to go much outside that range. > >>>> > >>>> However, it sounds like there's some objection to something > >>>> as small as one minute, so we need to negotiate an arbitrary > >>>> value here on the list. I'll start the bidding at twelve > >>>> minutes. > >>>> > >>>> /a > >>> > >>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>> J) > >> > >> > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > > > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 11:56:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25328; Thu, 9 Oct 2003 11:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d9z-0000Dh-00; Thu, 09 Oct 2003 11:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7d9z-0000De-00; Thu, 09 Oct 2003 11:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d9x-0003bT-PF; Thu, 09 Oct 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d9d-0003TI-Kt for simple@optimus.ietf.org; Thu, 09 Oct 2003 11:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25310 for ; Thu, 9 Oct 2003 11:56:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d9c-0000DG-00 for simple@ietf.org; Thu, 09 Oct 2003 11:56:40 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7d9b-0000CV-00 for simple@ietf.org; Thu, 09 Oct 2003 11:56:39 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h99Fu6Pp020347; Thu, 9 Oct 2003 11:56:06 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJQJL>; Thu, 9 Oct 2003 10:56:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E864EC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Miguel A. Garcia'" , Adam Roach Cc: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] Discovery of an MSRP relay MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 10:56:06 -0500 Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > ...but if by policy, I > have to use the MSRP provided in my home network, and I am > roaming, it > won't work. I don't see why not. Your home MSRP relay would be provisioned in your terminal, so it would know to go there. As an aside: what are you trying to do? The purpose of MSRP relays is to solve issues with firewalls and/or NATs. Why would you be tromboning back to your home network to find an MSRP relay? I mean, if you can get to your home network, it's a pretty good bet that you can hit the Internet as well, which should give you a clear shot to the other participant (or at least his relay). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 11:57:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25363 for ; Thu, 9 Oct 2003 11:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dA1-0003cH-FD for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 11:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Fv5XN013895 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 11:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dA1-0003c2-9u for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 11:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25328; Thu, 9 Oct 2003 11:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d9z-0000Dh-00; Thu, 09 Oct 2003 11:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7d9z-0000De-00; Thu, 09 Oct 2003 11:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d9x-0003bT-PF; Thu, 09 Oct 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7d9d-0003TI-Kt for simple@optimus.ietf.org; Thu, 09 Oct 2003 11:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25310 for ; Thu, 9 Oct 2003 11:56:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7d9c-0000DG-00 for simple@ietf.org; Thu, 09 Oct 2003 11:56:40 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7d9b-0000CV-00 for simple@ietf.org; Thu, 09 Oct 2003 11:56:39 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h99Fu6Pp020347; Thu, 9 Oct 2003 11:56:06 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJQJL>; Thu, 9 Oct 2003 10:56:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E864EC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Miguel A. Garcia'" , Adam Roach Cc: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] Discovery of an MSRP relay MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 10:56:06 -0500 Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > ...but if by policy, I > have to use the MSRP provided in my home network, and I am > roaming, it > won't work. I don't see why not. Your home MSRP relay would be provisioned in your terminal, so it would know to go there. As an aside: what are you trying to do? The purpose of MSRP relays is to solve issues with firewalls and/or NATs. Why would you be tromboning back to your home network to find an MSRP relay? I mean, if you can get to your home network, it's a pretty good bet that you can hit the Internet as well, which should give you a clear shot to the other participant (or at least his relay). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 15:47:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07313; Thu, 9 Oct 2003 15:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7glY-0003Sw-00; Thu, 09 Oct 2003 15:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7glY-0003St-00; Thu, 09 Oct 2003 15:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7glU-0003Yb-Qp; Thu, 09 Oct 2003 15:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7glB-0003Va-Bk for simple@optimus.ietf.org; Thu, 09 Oct 2003 15:47:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07272 for ; Thu, 9 Oct 2003 15:47:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gl9-0003SK-00 for simple@ietf.org; Thu, 09 Oct 2003 15:47:39 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7gl8-0003Rk-00 for simple@ietf.org; Thu, 09 Oct 2003 15:47:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h99Jl0d04388 for ; Thu, 9 Oct 2003 14:47:03 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1065728818.946.19.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE meeting in Minneapolis Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 14:46:58 -0500 Content-Transfer-Encoding: 7bit Folks - I've requested much more time for the upcoming IETF meeting (I expect to end up with 4.5 hrs total), but time will still be quite tight. I'm going to put together an agenda over the next couple of days that we can start bashing. If you are working on something new that you think should take some floor time, please bring me up to speed on it today or tomorrow. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 15:48:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07380 for ; Thu, 9 Oct 2003 15:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7glc-0003aT-75 for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 15:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Jm8tc013783 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 15:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7glc-0003aE-2j for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 15:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07313; Thu, 9 Oct 2003 15:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7glY-0003Sw-00; Thu, 09 Oct 2003 15:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7glY-0003St-00; Thu, 09 Oct 2003 15:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7glU-0003Yb-Qp; Thu, 09 Oct 2003 15:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7glB-0003Va-Bk for simple@optimus.ietf.org; Thu, 09 Oct 2003 15:47:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07272 for ; Thu, 9 Oct 2003 15:47:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gl9-0003SK-00 for simple@ietf.org; Thu, 09 Oct 2003 15:47:39 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7gl8-0003Rk-00 for simple@ietf.org; Thu, 09 Oct 2003 15:47:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h99Jl0d04388 for ; Thu, 9 Oct 2003 14:47:03 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1065728818.946.19.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE meeting in Minneapolis Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 14:46:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks - I've requested much more time for the upcoming IETF meeting (I expect to end up with 4.5 hrs total), but time will still be quite tight. I'm going to put together an agenda over the next couple of days that we can start bashing. If you are working on something new that you think should take some floor time, please bring me up to speed on it today or tomorrow. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 9 16:53:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10456; Thu, 9 Oct 2003 16:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hmY-0004OG-00; Thu, 09 Oct 2003 16:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7hmX-0004OB-00; Thu, 09 Oct 2003 16:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hmP-00078O-IU; Thu, 09 Oct 2003 16:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hlg-00077c-LJ for simple@optimus.ietf.org; Thu, 09 Oct 2003 16:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10435 for ; Thu, 9 Oct 2003 16:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hle-0004Ni-00 for simple@ietf.org; Thu, 09 Oct 2003 16:52:14 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7hld-0004NZ-00 for simple@ietf.org; Thu, 09 Oct 2003 16:52:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h99KpNd05500; Thu, 9 Oct 2003 15:51:23 -0500 From: Robert Sparks To: sip-implementors@cs.columbia.edu, simple@ietf.org In-Reply-To: <1064981329.882.29.camel@RjS.localdomain> References: <1064981329.882.29.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1065732680.936.35.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Reminder: SIMPLEt 2 registration is open Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 15:51:20 -0500 Content-Transfer-Encoding: 7bit Please visit http://simplet.jasomi.com/ to register at your earliest convenience. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 9 16:53:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10484 for ; Thu, 9 Oct 2003 16:53:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hmb-00079P-5R for simple-archive@odin.ietf.org; Thu, 09 Oct 2003 16:53:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99KrDtT027481 for simple-archive@odin.ietf.org; Thu, 9 Oct 2003 16:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hma-00079A-V2 for simple-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 16:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10456; Thu, 9 Oct 2003 16:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hmY-0004OG-00; Thu, 09 Oct 2003 16:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7hmX-0004OB-00; Thu, 09 Oct 2003 16:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hmP-00078O-IU; Thu, 09 Oct 2003 16:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hlg-00077c-LJ for simple@optimus.ietf.org; Thu, 09 Oct 2003 16:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10435 for ; Thu, 9 Oct 2003 16:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hle-0004Ni-00 for simple@ietf.org; Thu, 09 Oct 2003 16:52:14 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7hld-0004NZ-00 for simple@ietf.org; Thu, 09 Oct 2003 16:52:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h99KpNd05500; Thu, 9 Oct 2003 15:51:23 -0500 From: Robert Sparks To: sip-implementors@cs.columbia.edu, simple@ietf.org In-Reply-To: <1064981329.882.29.camel@RjS.localdomain> References: <1064981329.882.29.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1065732680.936.35.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Reminder: SIMPLEt 2 registration is open Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Oct 2003 15:51:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please visit http://simplet.jasomi.com/ to register at your earliest convenience. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 08:44:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25355; Fri, 10 Oct 2003 08:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wcq-0002n5-00; Fri, 10 Oct 2003 08:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7wcq-0002n2-00; Fri, 10 Oct 2003 08:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wci-00007g-Sa; Fri, 10 Oct 2003 08:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wbw-00006w-UQ for simple@optimus.ietf.org; Fri, 10 Oct 2003 08:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25312 for ; Fri, 10 Oct 2003 08:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wbv-0002lG-00 for simple@ietf.org; Fri, 10 Oct 2003 08:43:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7wbv-0002kS-00 for simple@ietf.org; Fri, 10 Oct 2003 08:43:11 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2003 05:39:05 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9ACgaXg026812; Fri, 10 Oct 2003 05:42:37 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADA88287; Fri, 10 Oct 2003 08:42:35 -0400 (EDT) Message-ID: <3F86A93B.1090102@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 08:42:35 -0400 Content-Transfer-Encoding: 7bit What Hisham says sounds good to me. I'm trying to think of a scenario where this makes a difference. I think I have one: Suppose there is an MSRP session between A and B, and involving a relay R1. Some administrator wants to shut down R1. This doesn't mean that A and B want to stop chatting. When the relay goes down, the chat applications will probably want to attempt renegotiation of the session, via a reINVITE. Assuming they can find a substitute relay, this should work ok. But there is of course the question of messages already sent: have they been delivered, or should they be sent again? If they are sent again, the recipient may see the same message appear twice. If the connection is just torn down (option 2) then A and B have no way of knowing whether the message outstanding were received, and so will have to assume no and retransmit. If option 1 is used, then the connection will go down smoothly and there will be no question, so no repeated messages. Paul hisham.khartabil@nokia.com wrote: > Does a 400 response for a SEND request terminate the MSRP session? If so, then option 1 (or a variant thereof) would be simple enough: A Relay refuses all SEND requests, once it has done so for every connection, it can assume all sessions are done and shut down. > > Of course option 2 is much SIMPLEr. > > /Hisham > > >>-----Original Message----- >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>Sent: Thursday, October 09, 2003 4:26 PM >>To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>simple@ietf.org >>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >> >> >>The only benefit I can see from using option 1 would be that an >>appropriate response/reason phrase to the SEND requests would allow a >>more graceful shutdown of sessions in an endpoint (The host of this >>session is terminating so I must dispose of the MSRP session) >>BUT I also >>see that option 2 keeps it SIMPLE ;-). >> >>Chris. >> >> >> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>Sent: 09 October 2003 14:13 >>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>> >>>I vote for option 2. >>> >>>/Hisham >>> >>> >>>>-----Original Message----- >>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>Sent: Wednesday, October 08, 2003 11:44 PM >>>>To: simple@ietf.org >>>>Subject: [Simple] MSRP: Administrative shutdown of relays >>>> >>>> >>>>I just realized that we had one more subject brought up in >>>>Vienna where >>>>we decided to "take it to the list". Which of course has not >>>>yet happened. >>>> >>>>The question was brought up that, in the previous version of >>>>MSRP where >>>>we refreshed state with BIND and VISIT, we had an implied >>>>mechanism by >>>>which a relay could shed load for shutdown. That is, is >>>>starts refusing >>>>refreshes until all sessions have expired. >>>> >>>>Since we have moved to a keep-alive approach rather than >>> >>the refresh >> >>>>approach, this is not as clean. A couple of approaches >>> >>come to mind: >> >>>>1) Start refusing _any_ SEND requests, then assume all the >>>>sessions are >>>>gone when the timeout period expires. >>>> >>>>2) Just close all TCP connections and let the endpoints >>> >>deal with it. >> >>>>I find myself leaning toward 2, as 1 does not allow the >>>>endpoints to do >>>>anything useful on the session anyway. >>>> >>>>Thoughts? >>>> >>>>Ben. >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 08:44:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25390 for ; Fri, 10 Oct 2003 08:44:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wcs-0000A2-EE for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 08:44:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ACiA16000619 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 08:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wcs-00009u-AO for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 08:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25355; Fri, 10 Oct 2003 08:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wcq-0002n5-00; Fri, 10 Oct 2003 08:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7wcq-0002n2-00; Fri, 10 Oct 2003 08:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wci-00007g-Sa; Fri, 10 Oct 2003 08:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wbw-00006w-UQ for simple@optimus.ietf.org; Fri, 10 Oct 2003 08:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25312 for ; Fri, 10 Oct 2003 08:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wbv-0002lG-00 for simple@ietf.org; Fri, 10 Oct 2003 08:43:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7wbv-0002kS-00 for simple@ietf.org; Fri, 10 Oct 2003 08:43:11 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2003 05:39:05 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9ACgaXg026812; Fri, 10 Oct 2003 05:42:37 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADA88287; Fri, 10 Oct 2003 08:42:35 -0400 (EDT) Message-ID: <3F86A93B.1090102@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 08:42:35 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What Hisham says sounds good to me. I'm trying to think of a scenario where this makes a difference. I think I have one: Suppose there is an MSRP session between A and B, and involving a relay R1. Some administrator wants to shut down R1. This doesn't mean that A and B want to stop chatting. When the relay goes down, the chat applications will probably want to attempt renegotiation of the session, via a reINVITE. Assuming they can find a substitute relay, this should work ok. But there is of course the question of messages already sent: have they been delivered, or should they be sent again? If they are sent again, the recipient may see the same message appear twice. If the connection is just torn down (option 2) then A and B have no way of knowing whether the message outstanding were received, and so will have to assume no and retransmit. If option 1 is used, then the connection will go down smoothly and there will be no question, so no repeated messages. Paul hisham.khartabil@nokia.com wrote: > Does a 400 response for a SEND request terminate the MSRP session? If so, then option 1 (or a variant thereof) would be simple enough: A Relay refuses all SEND requests, once it has done so for every connection, it can assume all sessions are done and shut down. > > Of course option 2 is much SIMPLEr. > > /Hisham > > >>-----Original Message----- >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>Sent: Thursday, October 09, 2003 4:26 PM >>To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>simple@ietf.org >>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >> >> >>The only benefit I can see from using option 1 would be that an >>appropriate response/reason phrase to the SEND requests would allow a >>more graceful shutdown of sessions in an endpoint (The host of this >>session is terminating so I must dispose of the MSRP session) >>BUT I also >>see that option 2 keeps it SIMPLE ;-). >> >>Chris. >> >> >> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>Sent: 09 October 2003 14:13 >>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>> >>>I vote for option 2. >>> >>>/Hisham >>> >>> >>>>-----Original Message----- >>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>Sent: Wednesday, October 08, 2003 11:44 PM >>>>To: simple@ietf.org >>>>Subject: [Simple] MSRP: Administrative shutdown of relays >>>> >>>> >>>>I just realized that we had one more subject brought up in >>>>Vienna where >>>>we decided to "take it to the list". Which of course has not >>>>yet happened. >>>> >>>>The question was brought up that, in the previous version of >>>>MSRP where >>>>we refreshed state with BIND and VISIT, we had an implied >>>>mechanism by >>>>which a relay could shed load for shutdown. That is, is >>>>starts refusing >>>>refreshes until all sessions have expired. >>>> >>>>Since we have moved to a keep-alive approach rather than >>> >>the refresh >> >>>>approach, this is not as clean. A couple of approaches >>> >>come to mind: >> >>>>1) Start refusing _any_ SEND requests, then assume all the >>>>sessions are >>>>gone when the timeout period expires. >>>> >>>>2) Just close all TCP connections and let the endpoints >>> >>deal with it. >> >>>>I find myself leaning toward 2, as 1 does not allow the >>>>endpoints to do >>>>anything useful on the session anyway. >>>> >>>>Thoughts? >>>> >>>>Ben. >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 10:37:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00736; Fri, 10 Oct 2003 10:37:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yOI-0004BU-00; Fri, 10 Oct 2003 10:37:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yOI-0004BR-00; Fri, 10 Oct 2003 10:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yO4-0006rF-Uw; Fri, 10 Oct 2003 10:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yND-0006iQ-RB for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00670 for ; Fri, 10 Oct 2003 10:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yNB-0004AV-00 for simple@ietf.org; Fri, 10 Oct 2003 10:36:05 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7yNA-0004AI-00 for simple@ietf.org; Fri, 10 Oct 2003 10:36:04 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AEZjeY096963; Fri, 10 Oct 2003 09:35:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F86C3B5.5010803@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> In-Reply-To: <3F86A93B.1090102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 09:35:33 -0500 Content-Transfer-Encoding: 7bit I had originally read Hisham's suggestion as having the relay wait for up to a full inactivity timeout between the time it stops allowing SEND and the time it drops the connections. Assuming this timer value is 10 (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. But in the case you mention, a full timeout would not be needed. Rather, just waiting a reasonable time to make sure that there are no SEND transactions in play would be sufficient. Is that what you had in mind? If so, I don't have a problem putting in as a SHOULD strength. Does anyone have thoughts on an appropriate response code for this? We already have 481 for no session, which seems borderline appropriate. We also have 500 which means "unable to forward SEND request" which is exactly the case but could be a little too generic. Is there a case where a client would handle a 500 different than some 5xx "relay shutting down" response? Paul Kyzivat wrote: > What Hisham says sounds good to me. > > I'm trying to think of a scenario where this makes a difference. I think > I have one: > > Suppose there is an MSRP session between A and B, and involving a relay > R1. Some administrator wants to shut down R1. This doesn't mean that A > and B want to stop chatting. When the relay goes down, the chat > applications will probably want to attempt renegotiation of the session, > via a reINVITE. > > Assuming they can find a substitute relay, this should work ok. But > there is of course the question of messages already sent: have they been > delivered, or should they be sent again? If they are sent again, the > recipient may see the same message appear twice. > > If the connection is just torn down (option 2) then A and B have no way > of knowing whether the message outstanding were received, and so will > have to assume no and retransmit. If option 1 is used, then the > connection will go down smoothly and there will be no question, so no > repeated messages. > > Paul > > hisham.khartabil@nokia.com wrote: > >> Does a 400 response for a SEND request terminate the MSRP session? If >> so, then option 1 (or a variant thereof) would be simple enough: A >> Relay refuses all SEND requests, once it has done so for every >> connection, it can assume all sessions are done and shut down. >> >> Of course option 2 is much SIMPLEr. >> >> /Hisham >> >> >>> -----Original Message----- >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>> Sent: Thursday, October 09, 2003 4:26 PM >>> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>> simple@ietf.org >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>> >>> >>> The only benefit I can see from using option 1 would be that an >>> appropriate response/reason phrase to the SEND requests would allow a >>> more graceful shutdown of sessions in an endpoint (The host of this >>> session is terminating so I must dispose of the MSRP session) BUT I also >>> see that option 2 keeps it SIMPLE ;-). >>> >>> Chris. >>> >>> >>> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>> Sent: 09 October 2003 14:13 >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>> >>>> I vote for option 2. >>>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>> Sent: Wednesday, October 08, 2003 11:44 PM >>>>> To: simple@ietf.org >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> >>>>> I just realized that we had one more subject brought up in >>>>> Vienna where >>>>> we decided to "take it to the list". Which of course has not >>>>> yet happened. >>>>> >>>>> The question was brought up that, in the previous version of >>>>> MSRP where >>>>> we refreshed state with BIND and VISIT, we had an implied >>>>> mechanism by >>>>> which a relay could shed load for shutdown. That is, is >>>>> starts refusing >>>>> refreshes until all sessions have expired. >>>>> >>>>> Since we have moved to a keep-alive approach rather than >>>> >>>> >>> the refresh >>> >>>>> approach, this is not as clean. A couple of approaches >>>> >>>> >>> come to mind: >>> >>>>> 1) Start refusing _any_ SEND requests, then assume all the >>>>> sessions are >>>>> gone when the timeout period expires. >>>>> >>>>> 2) Just close all TCP connections and let the endpoints >>>> >>>> >>> deal with it. >>> >>>>> I find myself leaning toward 2, as 1 does not allow the >>>>> endpoints to do >>>>> anything useful on the session anyway. >>>>> >>>>> Thoughts? >>>>> >>>>> Ben. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 10:37:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00775 for ; Fri, 10 Oct 2003 10:37:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yOL-0006x4-M1 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:37:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEbHFp026716 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yOL-0006wp-C1 for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:37:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00736; Fri, 10 Oct 2003 10:37:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yOI-0004BU-00; Fri, 10 Oct 2003 10:37:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yOI-0004BR-00; Fri, 10 Oct 2003 10:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yO4-0006rF-Uw; Fri, 10 Oct 2003 10:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yND-0006iQ-RB for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00670 for ; Fri, 10 Oct 2003 10:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yNB-0004AV-00 for simple@ietf.org; Fri, 10 Oct 2003 10:36:05 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7yNA-0004AI-00 for simple@ietf.org; Fri, 10 Oct 2003 10:36:04 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AEZjeY096963; Fri, 10 Oct 2003 09:35:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F86C3B5.5010803@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> In-Reply-To: <3F86A93B.1090102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 09:35:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I had originally read Hisham's suggestion as having the relay wait for up to a full inactivity timeout between the time it stops allowing SEND and the time it drops the connections. Assuming this timer value is 10 (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. But in the case you mention, a full timeout would not be needed. Rather, just waiting a reasonable time to make sure that there are no SEND transactions in play would be sufficient. Is that what you had in mind? If so, I don't have a problem putting in as a SHOULD strength. Does anyone have thoughts on an appropriate response code for this? We already have 481 for no session, which seems borderline appropriate. We also have 500 which means "unable to forward SEND request" which is exactly the case but could be a little too generic. Is there a case where a client would handle a 500 different than some 5xx "relay shutting down" response? Paul Kyzivat wrote: > What Hisham says sounds good to me. > > I'm trying to think of a scenario where this makes a difference. I think > I have one: > > Suppose there is an MSRP session between A and B, and involving a relay > R1. Some administrator wants to shut down R1. This doesn't mean that A > and B want to stop chatting. When the relay goes down, the chat > applications will probably want to attempt renegotiation of the session, > via a reINVITE. > > Assuming they can find a substitute relay, this should work ok. But > there is of course the question of messages already sent: have they been > delivered, or should they be sent again? If they are sent again, the > recipient may see the same message appear twice. > > If the connection is just torn down (option 2) then A and B have no way > of knowing whether the message outstanding were received, and so will > have to assume no and retransmit. If option 1 is used, then the > connection will go down smoothly and there will be no question, so no > repeated messages. > > Paul > > hisham.khartabil@nokia.com wrote: > >> Does a 400 response for a SEND request terminate the MSRP session? If >> so, then option 1 (or a variant thereof) would be simple enough: A >> Relay refuses all SEND requests, once it has done so for every >> connection, it can assume all sessions are done and shut down. >> >> Of course option 2 is much SIMPLEr. >> >> /Hisham >> >> >>> -----Original Message----- >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>> Sent: Thursday, October 09, 2003 4:26 PM >>> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>> simple@ietf.org >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>> >>> >>> The only benefit I can see from using option 1 would be that an >>> appropriate response/reason phrase to the SEND requests would allow a >>> more graceful shutdown of sessions in an endpoint (The host of this >>> session is terminating so I must dispose of the MSRP session) BUT I also >>> see that option 2 keeps it SIMPLE ;-). >>> >>> Chris. >>> >>> >>> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>> Sent: 09 October 2003 14:13 >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>> >>>> I vote for option 2. >>>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>> Sent: Wednesday, October 08, 2003 11:44 PM >>>>> To: simple@ietf.org >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> >>>>> I just realized that we had one more subject brought up in >>>>> Vienna where >>>>> we decided to "take it to the list". Which of course has not >>>>> yet happened. >>>>> >>>>> The question was brought up that, in the previous version of >>>>> MSRP where >>>>> we refreshed state with BIND and VISIT, we had an implied >>>>> mechanism by >>>>> which a relay could shed load for shutdown. That is, is >>>>> starts refusing >>>>> refreshes until all sessions have expired. >>>>> >>>>> Since we have moved to a keep-alive approach rather than >>>> >>>> >>> the refresh >>> >>>>> approach, this is not as clean. A couple of approaches >>>> >>>> >>> come to mind: >>> >>>>> 1) Start refusing _any_ SEND requests, then assume all the >>>>> sessions are >>>>> gone when the timeout period expires. >>>>> >>>>> 2) Just close all TCP connections and let the endpoints >>>> >>>> >>> deal with it. >>> >>>>> I find myself leaning toward 2, as 1 does not allow the >>>>> endpoints to do >>>>> anything useful on the session anyway. >>>>> >>>>> Thoughts? >>>>> >>>>> Ben. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 10:40:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00976; Fri, 10 Oct 2003 10:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yRy-0004GT-00; Fri, 10 Oct 2003 10:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yRx-0004GQ-00; Fri, 10 Oct 2003 10:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yRy-0007SE-Bo; Fri, 10 Oct 2003 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yR4-0007Qo-VP for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00910 for ; Fri, 10 Oct 2003 10:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yR1-0004Ep-00 for simple@ietf.org; Fri, 10 Oct 2003 10:40:03 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A7yR0-0004Em-00 for simple@ietf.org; Fri, 10 Oct 2003 10:40:02 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 10 Oct 2003 15:42:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE01E22E01@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcOPO87+Tfe/utvqRKu3OOZQ1bvHegAAECnA From: "Chris Boulton" To: "Ben Campbell" , "Paul Kyzivat" Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 15:39:26 +0100 Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 10 October 2003 15:36 >To: Paul Kyzivat >Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org >Subject: Re: [Simple] MSRP: Administrative shutdown of relays > >I had originally read Hisham's suggestion as having the relay wait for >up to a full inactivity timeout between the time it stops allowing SEND >and the time it drops the connections. Assuming this timer value is 10 >(or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > >But in the case you mention, a full timeout would not be needed. Rather, >just waiting a reasonable time to make sure that there are no SEND >transactions in play would be sufficient. Is that what you had in mind? >If so, I don't have a problem putting in as a SHOULD strength. > >Does anyone have thoughts on an appropriate response code for this? We >already have 481 for no session, which seems borderline appropriate. We >also have 500 which means "unable to forward SEND request" which is >exactly the case but could be a little too generic. Is there a case >where a client would handle a 500 different than some 5xx "relay >shutting down" response? [Chris Boulton] Not that I can think of - This should be enough information for a client to realize that this particular instance is un-available and I should try another relay. =20 > > > > > >Paul Kyzivat wrote: > >> What Hisham says sounds good to me. >> >> I'm trying to think of a scenario where this makes a difference. I think >> I have one: >> >> Suppose there is an MSRP session between A and B, and involving a relay >> R1. Some administrator wants to shut down R1. This doesn't mean that A >> and B want to stop chatting. When the relay goes down, the chat >> applications will probably want to attempt renegotiation of the session, >> via a reINVITE. >> >> Assuming they can find a substitute relay, this should work ok. But >> there is of course the question of messages already sent: have they been >> delivered, or should they be sent again? If they are sent again, the >> recipient may see the same message appear twice. >> >> If the connection is just torn down (option 2) then A and B have no way >> of knowing whether the message outstanding were received, and so will >> have to assume no and retransmit. If option 1 is used, then the >> connection will go down smoothly and there will be no question, so no >> repeated messages. >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >> >>> Does a 400 response for a SEND request terminate the MSRP session? If >>> so, then option 1 (or a variant thereof) would be simple enough: A >>> Relay refuses all SEND requests, once it has done so for every >>> connection, it can assume all sessions are done and shut down. >>> >>> Of course option 2 is much SIMPLEr. >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>> Sent: Thursday, October 09, 2003 4:26 PM >>>> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>>> simple@ietf.org >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>> >>>> >>>> The only benefit I can see from using option 1 would be that an >>>> appropriate response/reason phrase to the SEND requests would allow a >>>> more graceful shutdown of sessions in an endpoint (The host of this >>>> session is terminating so I must dispose of the MSRP session) BUT I >also >>>> see that option 2 keeps it SIMPLE ;-). >>>> >>>> Chris. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>> Sent: 09 October 2003 14:13 >>>>> To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> I vote for option 2. >>>>> >>>>> /Hisham >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>> Sent: Wednesday, October 08, 2003 11:44 PM >>>>>> To: simple@ietf.org >>>>>> Subject: [Simple] MSRP: Administrative shutdown of relays >>>>>> >>>>>> >>>>>> I just realized that we had one more subject brought up in >>>>>> Vienna where >>>>>> we decided to "take it to the list". Which of course has not >>>>>> yet happened. >>>>>> >>>>>> The question was brought up that, in the previous version of >>>>>> MSRP where >>>>>> we refreshed state with BIND and VISIT, we had an implied >>>>>> mechanism by >>>>>> which a relay could shed load for shutdown. That is, is >>>>>> starts refusing >>>>>> refreshes until all sessions have expired. >>>>>> >>>>>> Since we have moved to a keep-alive approach rather than >>>>> >>>>> >>>> the refresh >>>> >>>>>> approach, this is not as clean. A couple of approaches >>>>> >>>>> >>>> come to mind: >>>> >>>>>> 1) Start refusing _any_ SEND requests, then assume all the >>>>>> sessions are >>>>>> gone when the timeout period expires. >>>>>> >>>>>> 2) Just close all TCP connections and let the endpoints >>>>> >>>>> >>>> deal with it. >>>> >>>>>> I find myself leaning toward 2, as 1 does not allow the >>>>>> endpoints to do >>>>>> anything useful on the session anyway. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Ben. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 10:41:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01030 for ; Fri, 10 Oct 2003 10:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yS1-0007UE-No for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEf5bn028771 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yS1-0007TV-J4 for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:41:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00976; Fri, 10 Oct 2003 10:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yRy-0004GT-00; Fri, 10 Oct 2003 10:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yRx-0004GQ-00; Fri, 10 Oct 2003 10:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yRy-0007SE-Bo; Fri, 10 Oct 2003 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yR4-0007Qo-VP for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00910 for ; Fri, 10 Oct 2003 10:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yR1-0004Ep-00 for simple@ietf.org; Fri, 10 Oct 2003 10:40:03 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A7yR0-0004Em-00 for simple@ietf.org; Fri, 10 Oct 2003 10:40:02 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 10 Oct 2003 15:42:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE01E22E01@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcOPO87+Tfe/utvqRKu3OOZQ1bvHegAAECnA From: "Chris Boulton" To: "Ben Campbell" , "Paul Kyzivat" Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 15:39:26 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 10 October 2003 15:36 >To: Paul Kyzivat >Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org >Subject: Re: [Simple] MSRP: Administrative shutdown of relays > >I had originally read Hisham's suggestion as having the relay wait for >up to a full inactivity timeout between the time it stops allowing SEND >and the time it drops the connections. Assuming this timer value is 10 >(or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > >But in the case you mention, a full timeout would not be needed. Rather, >just waiting a reasonable time to make sure that there are no SEND >transactions in play would be sufficient. Is that what you had in mind? >If so, I don't have a problem putting in as a SHOULD strength. > >Does anyone have thoughts on an appropriate response code for this? We >already have 481 for no session, which seems borderline appropriate. We >also have 500 which means "unable to forward SEND request" which is >exactly the case but could be a little too generic. Is there a case >where a client would handle a 500 different than some 5xx "relay >shutting down" response? [Chris Boulton] Not that I can think of - This should be enough information for a client to realize that this particular instance is un-available and I should try another relay. =20 > > > > > >Paul Kyzivat wrote: > >> What Hisham says sounds good to me. >> >> I'm trying to think of a scenario where this makes a difference. I think >> I have one: >> >> Suppose there is an MSRP session between A and B, and involving a relay >> R1. Some administrator wants to shut down R1. This doesn't mean that A >> and B want to stop chatting. When the relay goes down, the chat >> applications will probably want to attempt renegotiation of the session, >> via a reINVITE. >> >> Assuming they can find a substitute relay, this should work ok. But >> there is of course the question of messages already sent: have they been >> delivered, or should they be sent again? If they are sent again, the >> recipient may see the same message appear twice. >> >> If the connection is just torn down (option 2) then A and B have no way >> of knowing whether the message outstanding were received, and so will >> have to assume no and retransmit. If option 1 is used, then the >> connection will go down smoothly and there will be no question, so no >> repeated messages. >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >> >>> Does a 400 response for a SEND request terminate the MSRP session? If >>> so, then option 1 (or a variant thereof) would be simple enough: A >>> Relay refuses all SEND requests, once it has done so for every >>> connection, it can assume all sessions are done and shut down. >>> >>> Of course option 2 is much SIMPLEr. >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>> Sent: Thursday, October 09, 2003 4:26 PM >>>> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>>> simple@ietf.org >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>> >>>> >>>> The only benefit I can see from using option 1 would be that an >>>> appropriate response/reason phrase to the SEND requests would allow a >>>> more graceful shutdown of sessions in an endpoint (The host of this >>>> session is terminating so I must dispose of the MSRP session) BUT I >also >>>> see that option 2 keeps it SIMPLE ;-). >>>> >>>> Chris. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>> Sent: 09 October 2003 14:13 >>>>> To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> I vote for option 2. >>>>> >>>>> /Hisham >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>> Sent: Wednesday, October 08, 2003 11:44 PM >>>>>> To: simple@ietf.org >>>>>> Subject: [Simple] MSRP: Administrative shutdown of relays >>>>>> >>>>>> >>>>>> I just realized that we had one more subject brought up in >>>>>> Vienna where >>>>>> we decided to "take it to the list". Which of course has not >>>>>> yet happened. >>>>>> >>>>>> The question was brought up that, in the previous version of >>>>>> MSRP where >>>>>> we refreshed state with BIND and VISIT, we had an implied >>>>>> mechanism by >>>>>> which a relay could shed load for shutdown. That is, is >>>>>> starts refusing >>>>>> refreshes until all sessions have expired. >>>>>> >>>>>> Since we have moved to a keep-alive approach rather than >>>>> >>>>> >>>> the refresh >>>> >>>>>> approach, this is not as clean. A couple of approaches >>>>> >>>>> >>>> come to mind: >>>> >>>>>> 1) Start refusing _any_ SEND requests, then assume all the >>>>>> sessions are >>>>>> gone when the timeout period expires. >>>>>> >>>>>> 2) Just close all TCP connections and let the endpoints >>>>> >>>>> >>>> deal with it. >>>> >>>>>> I find myself leaning toward 2, as 1 does not allow the >>>>>> endpoints to do >>>>>> anything useful on the session anyway. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Ben. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 10:45:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01272; Fri, 10 Oct 2003 10:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yWs-0004NW-00; Fri, 10 Oct 2003 10:46:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yWs-0004NT-00; Fri, 10 Oct 2003 10:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yWn-0007km-P0; Fri, 10 Oct 2003 10:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yWJ-0007hu-0e for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:45:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01237 for ; Fri, 10 Oct 2003 10:45:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yWG-0004MA-00 for simple@ietf.org; Fri, 10 Oct 2003 10:45:28 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7yWF-0004M7-00 for simple@ietf.org; Fri, 10 Oct 2003 10:45:27 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9AEjOP23202 for ; Fri, 10 Oct 2003 17:45:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 Oct 2003 17:45:22 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 17:45:22 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 17:45:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcOPO99V83OQqUo0Tne9tOF5JQ75sQAANFXw To: , Cc: , X-OriginalArrivalTime: 10 Oct 2003 14:45:22.0331 (UTC) FILETIME=[22092EB0:01C38F3D] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 17:45:21 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, October 10, 2003 5:36 PM > To: Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > I had originally read Hisham's suggestion as having the relay=20 > wait for=20 > up to a full inactivity timeout between the time it stops=20 > allowing SEND=20 > and the time it drops the connections. Assuming this timer=20 > value is 10=20 > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. No, I suggested that either the relay waits the full timeout, or until = it know it has sent 4xx (or 5xx) response to SEND requests sent by all = the participants in all session. Whichever is reached first. Regards, Hisham >=20 > But in the case you mention, a full timeout would not be=20 > needed. Rather,=20 > just waiting a reasonable time to make sure that there are no SEND=20 > transactions in play would be sufficient. Is that what you=20 > had in mind?=20 > If so, I don't have a problem putting in as a SHOULD strength. >=20 > Does anyone have thoughts on an appropriate response code for=20 > this? We=20 > already have 481 for no session, which seems borderline=20 > appropriate. We=20 > also have 500 which means "unable to forward SEND request" which is=20 > exactly the case but could be a little too generic. Is there a case=20 > where a client would handle a 500 different than some 5xx "relay=20 > shutting down" response? >=20 >=20 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > What Hisham says sounds good to me. > >=20 > > I'm trying to think of a scenario where this makes a=20 > difference. I think=20 > > I have one: > >=20 > > Suppose there is an MSRP session between A and B, and=20 > involving a relay=20 > > R1. Some administrator wants to shut down R1. This doesn't=20 > mean that A=20 > > and B want to stop chatting. When the relay goes down, the chat=20 > > applications will probably want to attempt renegotiation of=20 > the session,=20 > > via a reINVITE. > >=20 > > Assuming they can find a substitute relay, this should work ok. But=20 > > there is of course the question of messages already sent:=20 > have they been=20 > > delivered, or should they be sent again? If they are sent=20 > again, the=20 > > recipient may see the same message appear twice. > >=20 > > If the connection is just torn down (option 2) then A and B=20 > have no way=20 > > of knowing whether the message outstanding were received,=20 > and so will=20 > > have to assume no and retransmit. If option 1 is used, then the=20 > > connection will go down smoothly and there will be no=20 > question, so no=20 > > repeated messages. > >=20 > > Paul > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > >> Does a 400 response for a SEND request terminate the MSRP=20 > session? If=20 > >> so, then option 1 (or a variant thereof) would be simple enough: A=20 > >> Relay refuses all SEND requests, once it has done so for every=20 > >> connection, it can assume all sessions are done and shut down. > >> > >> Of course option 2 is much SIMPLEr. > >> > >> /Hisham > >> > >> > >>> -----Original Message----- > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > >>> Sent: Thursday, October 09, 2003 4:26 PM > >>> To: Khartabil Hisham (NMP-MSW/Helsinki);=20 > bcampbell@dynamicsoft.com; > >>> simple@ietf.org > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>> > >>> > >>> The only benefit I can see from using option 1 would be that an > >>> appropriate response/reason phrase to the SEND requests=20 > would allow a > >>> more graceful shutdown of sessions in an endpoint (The=20 > host of this > >>> session is terminating so I must dispose of the MSRP=20 > session) BUT I also > >>> see that option 2 keeps it SIMPLE ;-). > >>> > >>> Chris. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >>>> Sent: 09 October 2003 14:13 > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>>> > >>>> I vote for option 2. > >>>> > >>>> /Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > >>>>> To: simple@ietf.org > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > >>>>> > >>>>> > >>>>> I just realized that we had one more subject brought up in > >>>>> Vienna where > >>>>> we decided to "take it to the list". Which of course has not > >>>>> yet happened. > >>>>> > >>>>> The question was brought up that, in the previous version of > >>>>> MSRP where > >>>>> we refreshed state with BIND and VISIT, we had an implied > >>>>> mechanism by > >>>>> which a relay could shed load for shutdown. That is, is > >>>>> starts refusing > >>>>> refreshes until all sessions have expired. > >>>>> > >>>>> Since we have moved to a keep-alive approach rather than=20 > >>>> > >>>> > >>> the refresh > >>> > >>>>> approach, this is not as clean. A couple of approaches=20 > >>>> > >>>> > >>> come to mind: > >>> > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > >>>>> sessions are > >>>>> gone when the timeout period expires. > >>>>> > >>>>> 2) Just close all TCP connections and let the endpoints=20 > >>>> > >>>> > >>> deal with it. > >>> > >>>>> I find myself leaning toward 2, as 1 does not allow the > >>>>> endpoints to do > >>>>> anything useful on the session anyway. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Ben. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 10:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01331 for ; Fri, 10 Oct 2003 10:46:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yWw-0007nm-4E for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:46:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEkAqK029984 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yWv-0007nX-Vt for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01272; Fri, 10 Oct 2003 10:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yWs-0004NW-00; Fri, 10 Oct 2003 10:46:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yWs-0004NT-00; Fri, 10 Oct 2003 10:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yWn-0007km-P0; Fri, 10 Oct 2003 10:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yWJ-0007hu-0e for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:45:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01237 for ; Fri, 10 Oct 2003 10:45:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yWG-0004MA-00 for simple@ietf.org; Fri, 10 Oct 2003 10:45:28 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7yWF-0004M7-00 for simple@ietf.org; Fri, 10 Oct 2003 10:45:27 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9AEjOP23202 for ; Fri, 10 Oct 2003 17:45:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 Oct 2003 17:45:22 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 17:45:22 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 17:45:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcOPO99V83OQqUo0Tne9tOF5JQ75sQAANFXw To: , Cc: , X-OriginalArrivalTime: 10 Oct 2003 14:45:22.0331 (UTC) FILETIME=[22092EB0:01C38F3D] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 17:45:21 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, October 10, 2003 5:36 PM > To: Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > I had originally read Hisham's suggestion as having the relay=20 > wait for=20 > up to a full inactivity timeout between the time it stops=20 > allowing SEND=20 > and the time it drops the connections. Assuming this timer=20 > value is 10=20 > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. No, I suggested that either the relay waits the full timeout, or until = it know it has sent 4xx (or 5xx) response to SEND requests sent by all = the participants in all session. Whichever is reached first. Regards, Hisham >=20 > But in the case you mention, a full timeout would not be=20 > needed. Rather,=20 > just waiting a reasonable time to make sure that there are no SEND=20 > transactions in play would be sufficient. Is that what you=20 > had in mind?=20 > If so, I don't have a problem putting in as a SHOULD strength. >=20 > Does anyone have thoughts on an appropriate response code for=20 > this? We=20 > already have 481 for no session, which seems borderline=20 > appropriate. We=20 > also have 500 which means "unable to forward SEND request" which is=20 > exactly the case but could be a little too generic. Is there a case=20 > where a client would handle a 500 different than some 5xx "relay=20 > shutting down" response? >=20 >=20 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > What Hisham says sounds good to me. > >=20 > > I'm trying to think of a scenario where this makes a=20 > difference. I think=20 > > I have one: > >=20 > > Suppose there is an MSRP session between A and B, and=20 > involving a relay=20 > > R1. Some administrator wants to shut down R1. This doesn't=20 > mean that A=20 > > and B want to stop chatting. When the relay goes down, the chat=20 > > applications will probably want to attempt renegotiation of=20 > the session,=20 > > via a reINVITE. > >=20 > > Assuming they can find a substitute relay, this should work ok. But=20 > > there is of course the question of messages already sent:=20 > have they been=20 > > delivered, or should they be sent again? If they are sent=20 > again, the=20 > > recipient may see the same message appear twice. > >=20 > > If the connection is just torn down (option 2) then A and B=20 > have no way=20 > > of knowing whether the message outstanding were received,=20 > and so will=20 > > have to assume no and retransmit. If option 1 is used, then the=20 > > connection will go down smoothly and there will be no=20 > question, so no=20 > > repeated messages. > >=20 > > Paul > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > >> Does a 400 response for a SEND request terminate the MSRP=20 > session? If=20 > >> so, then option 1 (or a variant thereof) would be simple enough: A=20 > >> Relay refuses all SEND requests, once it has done so for every=20 > >> connection, it can assume all sessions are done and shut down. > >> > >> Of course option 2 is much SIMPLEr. > >> > >> /Hisham > >> > >> > >>> -----Original Message----- > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > >>> Sent: Thursday, October 09, 2003 4:26 PM > >>> To: Khartabil Hisham (NMP-MSW/Helsinki);=20 > bcampbell@dynamicsoft.com; > >>> simple@ietf.org > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>> > >>> > >>> The only benefit I can see from using option 1 would be that an > >>> appropriate response/reason phrase to the SEND requests=20 > would allow a > >>> more graceful shutdown of sessions in an endpoint (The=20 > host of this > >>> session is terminating so I must dispose of the MSRP=20 > session) BUT I also > >>> see that option 2 keeps it SIMPLE ;-). > >>> > >>> Chris. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >>>> Sent: 09 October 2003 14:13 > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>>> > >>>> I vote for option 2. > >>>> > >>>> /Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > >>>>> To: simple@ietf.org > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > >>>>> > >>>>> > >>>>> I just realized that we had one more subject brought up in > >>>>> Vienna where > >>>>> we decided to "take it to the list". Which of course has not > >>>>> yet happened. > >>>>> > >>>>> The question was brought up that, in the previous version of > >>>>> MSRP where > >>>>> we refreshed state with BIND and VISIT, we had an implied > >>>>> mechanism by > >>>>> which a relay could shed load for shutdown. That is, is > >>>>> starts refusing > >>>>> refreshes until all sessions have expired. > >>>>> > >>>>> Since we have moved to a keep-alive approach rather than=20 > >>>> > >>>> > >>> the refresh > >>> > >>>>> approach, this is not as clean. A couple of approaches=20 > >>>> > >>>> > >>> come to mind: > >>> > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > >>>>> sessions are > >>>>> gone when the timeout period expires. > >>>>> > >>>>> 2) Just close all TCP connections and let the endpoints=20 > >>>> > >>>> > >>> deal with it. > >>> > >>>>> I find myself leaning toward 2, as 1 does not allow the > >>>>> endpoints to do > >>>>> anything useful on the session anyway. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Ben. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 10:47:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01393; Fri, 10 Oct 2003 10:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yY0-0004Px-00; Fri, 10 Oct 2003 10:47:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yY0-0004Pu-00; Fri, 10 Oct 2003 10:47:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yXo-0007zB-HC; Fri, 10 Oct 2003 10:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yXL-0007s7-3a for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:46:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01329 for ; Fri, 10 Oct 2003 10:46:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yXI-0004Oj-00 for simple@ietf.org; Fri, 10 Oct 2003 10:46:32 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7yXH-0004Mc-00 for simple@ietf.org; Fri, 10 Oct 2003 10:46:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9AEjvd22345 for ; Fri, 10 Oct 2003 09:45:57 -0500 From: Robert Sparks To: simple@ietf.org In-Reply-To: <3F86C3B5.5010803@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> Content-Type: text/plain Message-Id: <1065797156.981.32.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Overload (was MSRP: Administrative shutdown of relays) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 09:45:57 -0500 Content-Transfer-Encoding: 7bit (as not-the-chair): It occurs to me that we have another scenario that deserves exploration. What do we have a relay do when it reaches capacity? Rejecting new binds is obvious, but what do we do when traffic on existing sessions begins to overwhelm the relay? Beginning to terminate some of them by 481ing selected SENDs would help, but that would likely result in an immediate reattempt to BIND (along with a TCP connect). Do we want to avoid that and have some way to say "Go away and don't bother me again until x amount of time has passed"? RjS On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > I had originally read Hisham's suggestion as having the relay wait for > up to a full inactivity timeout between the time it stops allowing SEND > and the time it drops the connections. Assuming this timer value is 10 > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > > But in the case you mention, a full timeout would not be needed. Rather, > just waiting a reasonable time to make sure that there are no SEND > transactions in play would be sufficient. Is that what you had in mind? > If so, I don't have a problem putting in as a SHOULD strength. > > Does anyone have thoughts on an appropriate response code for this? We > already have 481 for no session, which seems borderline appropriate. We > also have 500 which means "unable to forward SEND request" which is > exactly the case but could be a little too generic. Is there a case > where a client would handle a 500 different than some 5xx "relay > shutting down" response? > > > > > > Paul Kyzivat wrote: > > > What Hisham says sounds good to me. > > > > I'm trying to think of a scenario where this makes a difference. I think > > I have one: > > > > Suppose there is an MSRP session between A and B, and involving a relay > > R1. Some administrator wants to shut down R1. This doesn't mean that A > > and B want to stop chatting. When the relay goes down, the chat > > applications will probably want to attempt renegotiation of the session, > > via a reINVITE. > > > > Assuming they can find a substitute relay, this should work ok. But > > there is of course the question of messages already sent: have they been > > delivered, or should they be sent again? If they are sent again, the > > recipient may see the same message appear twice. > > > > If the connection is just torn down (option 2) then A and B have no way > > of knowing whether the message outstanding were received, and so will > > have to assume no and retransmit. If option 1 is used, then the > > connection will go down smoothly and there will be no question, so no > > repeated messages. > > > > Paul > > > > hisham.khartabil@nokia.com wrote: > > > >> Does a 400 response for a SEND request terminate the MSRP session? If > >> so, then option 1 (or a variant thereof) would be simple enough: A > >> Relay refuses all SEND requests, once it has done so for every > >> connection, it can assume all sessions are done and shut down. > >> > >> Of course option 2 is much SIMPLEr. > >> > >> /Hisham > >> > >> > >>> -----Original Message----- > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > >>> Sent: Thursday, October 09, 2003 4:26 PM > >>> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; > >>> simple@ietf.org > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>> > >>> > >>> The only benefit I can see from using option 1 would be that an > >>> appropriate response/reason phrase to the SEND requests would allow a > >>> more graceful shutdown of sessions in an endpoint (The host of this > >>> session is terminating so I must dispose of the MSRP session) BUT I also > >>> see that option 2 keeps it SIMPLE ;-). > >>> > >>> Chris. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >>>> Sent: 09 October 2003 14:13 > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>>> > >>>> I vote for option 2. > >>>> > >>>> /Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > >>>>> To: simple@ietf.org > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > >>>>> > >>>>> > >>>>> I just realized that we had one more subject brought up in > >>>>> Vienna where > >>>>> we decided to "take it to the list". Which of course has not > >>>>> yet happened. > >>>>> > >>>>> The question was brought up that, in the previous version of > >>>>> MSRP where > >>>>> we refreshed state with BIND and VISIT, we had an implied > >>>>> mechanism by > >>>>> which a relay could shed load for shutdown. That is, is > >>>>> starts refusing > >>>>> refreshes until all sessions have expired. > >>>>> > >>>>> Since we have moved to a keep-alive approach rather than > >>>> > >>>> > >>> the refresh > >>> > >>>>> approach, this is not as clean. A couple of approaches > >>>> > >>>> > >>> come to mind: > >>> > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > >>>>> sessions are > >>>>> gone when the timeout period expires. > >>>>> > >>>>> 2) Just close all TCP connections and let the endpoints > >>>> > >>>> > >>> deal with it. > >>> > >>>>> I find myself leaning toward 2, as 1 does not allow the > >>>>> endpoints to do > >>>>> anything useful on the session anyway. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Ben. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 10:47:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01438 for ; Fri, 10 Oct 2003 10:47:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yY4-000847-1y for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:47:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AElKTx030997 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 10:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yY3-00083s-PV for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01393; Fri, 10 Oct 2003 10:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yY0-0004Px-00; Fri, 10 Oct 2003 10:47:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yY0-0004Pu-00; Fri, 10 Oct 2003 10:47:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yXo-0007zB-HC; Fri, 10 Oct 2003 10:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yXL-0007s7-3a for simple@optimus.ietf.org; Fri, 10 Oct 2003 10:46:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01329 for ; Fri, 10 Oct 2003 10:46:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yXI-0004Oj-00 for simple@ietf.org; Fri, 10 Oct 2003 10:46:32 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7yXH-0004Mc-00 for simple@ietf.org; Fri, 10 Oct 2003 10:46:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9AEjvd22345 for ; Fri, 10 Oct 2003 09:45:57 -0500 From: Robert Sparks To: simple@ietf.org In-Reply-To: <3F86C3B5.5010803@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> Content-Type: text/plain Message-Id: <1065797156.981.32.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Overload (was MSRP: Administrative shutdown of relays) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 09:45:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (as not-the-chair): It occurs to me that we have another scenario that deserves exploration. What do we have a relay do when it reaches capacity? Rejecting new binds is obvious, but what do we do when traffic on existing sessions begins to overwhelm the relay? Beginning to terminate some of them by 481ing selected SENDs would help, but that would likely result in an immediate reattempt to BIND (along with a TCP connect). Do we want to avoid that and have some way to say "Go away and don't bother me again until x amount of time has passed"? RjS On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > I had originally read Hisham's suggestion as having the relay wait for > up to a full inactivity timeout between the time it stops allowing SEND > and the time it drops the connections. Assuming this timer value is 10 > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > > But in the case you mention, a full timeout would not be needed. Rather, > just waiting a reasonable time to make sure that there are no SEND > transactions in play would be sufficient. Is that what you had in mind? > If so, I don't have a problem putting in as a SHOULD strength. > > Does anyone have thoughts on an appropriate response code for this? We > already have 481 for no session, which seems borderline appropriate. We > also have 500 which means "unable to forward SEND request" which is > exactly the case but could be a little too generic. Is there a case > where a client would handle a 500 different than some 5xx "relay > shutting down" response? > > > > > > Paul Kyzivat wrote: > > > What Hisham says sounds good to me. > > > > I'm trying to think of a scenario where this makes a difference. I think > > I have one: > > > > Suppose there is an MSRP session between A and B, and involving a relay > > R1. Some administrator wants to shut down R1. This doesn't mean that A > > and B want to stop chatting. When the relay goes down, the chat > > applications will probably want to attempt renegotiation of the session, > > via a reINVITE. > > > > Assuming they can find a substitute relay, this should work ok. But > > there is of course the question of messages already sent: have they been > > delivered, or should they be sent again? If they are sent again, the > > recipient may see the same message appear twice. > > > > If the connection is just torn down (option 2) then A and B have no way > > of knowing whether the message outstanding were received, and so will > > have to assume no and retransmit. If option 1 is used, then the > > connection will go down smoothly and there will be no question, so no > > repeated messages. > > > > Paul > > > > hisham.khartabil@nokia.com wrote: > > > >> Does a 400 response for a SEND request terminate the MSRP session? If > >> so, then option 1 (or a variant thereof) would be simple enough: A > >> Relay refuses all SEND requests, once it has done so for every > >> connection, it can assume all sessions are done and shut down. > >> > >> Of course option 2 is much SIMPLEr. > >> > >> /Hisham > >> > >> > >>> -----Original Message----- > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > >>> Sent: Thursday, October 09, 2003 4:26 PM > >>> To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; > >>> simple@ietf.org > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>> > >>> > >>> The only benefit I can see from using option 1 would be that an > >>> appropriate response/reason phrase to the SEND requests would allow a > >>> more graceful shutdown of sessions in an endpoint (The host of this > >>> session is terminating so I must dispose of the MSRP session) BUT I also > >>> see that option 2 keeps it SIMPLE ;-). > >>> > >>> Chris. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >>>> Sent: 09 October 2003 14:13 > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > >>>> > >>>> I vote for option 2. > >>>> > >>>> /Hisham > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > >>>>> To: simple@ietf.org > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > >>>>> > >>>>> > >>>>> I just realized that we had one more subject brought up in > >>>>> Vienna where > >>>>> we decided to "take it to the list". Which of course has not > >>>>> yet happened. > >>>>> > >>>>> The question was brought up that, in the previous version of > >>>>> MSRP where > >>>>> we refreshed state with BIND and VISIT, we had an implied > >>>>> mechanism by > >>>>> which a relay could shed load for shutdown. That is, is > >>>>> starts refusing > >>>>> refreshes until all sessions have expired. > >>>>> > >>>>> Since we have moved to a keep-alive approach rather than > >>>> > >>>> > >>> the refresh > >>> > >>>>> approach, this is not as clean. A couple of approaches > >>>> > >>>> > >>> come to mind: > >>> > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > >>>>> sessions are > >>>>> gone when the timeout period expires. > >>>>> > >>>>> 2) Just close all TCP connections and let the endpoints > >>>> > >>>> > >>> deal with it. > >>> > >>>>> I find myself leaning toward 2, as 1 does not allow the > >>>>> endpoints to do > >>>>> anything useful on the session anyway. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Ben. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 11:07:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02466; Fri, 10 Oct 2003 11:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ysA-0004kp-00; Fri, 10 Oct 2003 11:08:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ys9-0004km-00; Fri, 10 Oct 2003 11:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ys4-0001DB-Nt; Fri, 10 Oct 2003 11:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yrQ-00012u-33 for simple@optimus.ietf.org; Fri, 10 Oct 2003 11:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02415 for ; Fri, 10 Oct 2003 11:07:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yrN-0004j6-00 for simple@ietf.org; Fri, 10 Oct 2003 11:07:17 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7yrM-0004j2-00 for simple@ietf.org; Fri, 10 Oct 2003 11:07:16 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AF6teY099362; Fri, 10 Oct 2003 10:07:02 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F86CB03.5000908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 10:06:43 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, October 10, 2003 5:36 PM >>To: Paul Kyzivat >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >>simple@ietf.org >>Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >>I had originally read Hisham's suggestion as having the relay >>wait for >>up to a full inactivity timeout between the time it stops >>allowing SEND >>and the time it drops the connections. Assuming this timer >>value is 10 >>(or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > > > No, I suggested that either the relay waits the full timeout, or until it know it has sent 4xx (or 5xx) response to SEND requests sent by all the participants in all session. Whichever is reached first. That is not far from the same thing, since if there was a single idle session, it will take up to 1 timeout for each endpoint to send a request that the relay could respond to. But my point was, for Paul's scenario, it is not neccessary to wait for idle endpoints to get around to sending a request. You just have to wait long enough so that it is very unlikely that any transactions are still in play. A small number of minutes should be plenty of time. > > Regards, > Hisham > > >>But in the case you mention, a full timeout would not be >>needed. Rather, >>just waiting a reasonable time to make sure that there are no SEND >>transactions in play would be sufficient. Is that what you >>had in mind? >>If so, I don't have a problem putting in as a SHOULD strength. >> >>Does anyone have thoughts on an appropriate response code for >>this? We >>already have 481 for no session, which seems borderline >>appropriate. We >>also have 500 which means "unable to forward SEND request" which is >>exactly the case but could be a little too generic. Is there a case >>where a client would handle a 500 different than some 5xx "relay >>shutting down" response? >> >> >> >> >> >>Paul Kyzivat wrote: >> >> >>>What Hisham says sounds good to me. >>> >>>I'm trying to think of a scenario where this makes a >> >>difference. I think >> >>>I have one: >>> >>>Suppose there is an MSRP session between A and B, and >> >>involving a relay >> >>>R1. Some administrator wants to shut down R1. This doesn't >> >>mean that A >> >>>and B want to stop chatting. When the relay goes down, the chat >>>applications will probably want to attempt renegotiation of >> >>the session, >> >>>via a reINVITE. >>> >>>Assuming they can find a substitute relay, this should work ok. But >>>there is of course the question of messages already sent: >> >>have they been >> >>>delivered, or should they be sent again? If they are sent >> >>again, the >> >>>recipient may see the same message appear twice. >>> >>>If the connection is just torn down (option 2) then A and B >> >>have no way >> >>>of knowing whether the message outstanding were received, >> >>and so will >> >>>have to assume no and retransmit. If option 1 is used, then the >>>connection will go down smoothly and there will be no >> >>question, so no >> >>>repeated messages. >>> >>> Paul >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>Does a 400 response for a SEND request terminate the MSRP >> >>session? If >> >>>>so, then option 1 (or a variant thereof) would be simple enough: A >>>>Relay refuses all SEND requests, once it has done so for every >>>>connection, it can assume all sessions are done and shut down. >>>> >>>>Of course option 2 is much SIMPLEr. >>>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>>Sent: Thursday, October 09, 2003 4:26 PM >>>>>To: Khartabil Hisham (NMP-MSW/Helsinki); >> >>bcampbell@dynamicsoft.com; >> >>>>>simple@ietf.org >>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> >>>>>The only benefit I can see from using option 1 would be that an >>>>>appropriate response/reason phrase to the SEND requests >> >>would allow a >> >>>>>more graceful shutdown of sessions in an endpoint (The >> >>host of this >> >>>>>session is terminating so I must dispose of the MSRP >> >>session) BUT I also >> >>>>>see that option 2 keeps it SIMPLE ;-). >>>>> >>>>>Chris. >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: hisham.khartabil@nokia.com >> >>[mailto:hisham.khartabil@nokia.com] >> >>>>>>Sent: 09 October 2003 14:13 >>>>>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>>> >>>>>>I vote for option 2. >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>>>Sent: Wednesday, October 08, 2003 11:44 PM >>>>>>>To: simple@ietf.org >>>>>>>Subject: [Simple] MSRP: Administrative shutdown of relays >>>>>>> >>>>>>> >>>>>>>I just realized that we had one more subject brought up in >>>>>>>Vienna where >>>>>>>we decided to "take it to the list". Which of course has not >>>>>>>yet happened. >>>>>>> >>>>>>>The question was brought up that, in the previous version of >>>>>>>MSRP where >>>>>>>we refreshed state with BIND and VISIT, we had an implied >>>>>>>mechanism by >>>>>>>which a relay could shed load for shutdown. That is, is >>>>>>>starts refusing >>>>>>>refreshes until all sessions have expired. >>>>>>> >>>>>>>Since we have moved to a keep-alive approach rather than >>>>>> >>>>>> >>>>>the refresh >>>>> >>>>> >>>>>>>approach, this is not as clean. A couple of approaches >>>>>> >>>>>> >>>>>come to mind: >>>>> >>>>> >>>>>>>1) Start refusing _any_ SEND requests, then assume all the >>>>>>>sessions are >>>>>>>gone when the timeout period expires. >>>>>>> >>>>>>>2) Just close all TCP connections and let the endpoints >>>>>> >>>>>> >>>>>deal with it. >>>>> >>>>> >>>>>>>I find myself leaning toward 2, as 1 does not allow the >>>>>>>endpoints to do >>>>>>>anything useful on the session anyway. >>>>>>> >>>>>>>Thoughts? >>>>>>> >>>>>>>Ben. >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Simple mailing list >>>>>>>Simple@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 11:08:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02540 for ; Fri, 10 Oct 2003 11:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ysF-0001Fc-8q for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 11:08:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AF8AP3004802 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 11:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ysD-0001FN-Ae for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 11:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02466; Fri, 10 Oct 2003 11:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ysA-0004kp-00; Fri, 10 Oct 2003 11:08:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ys9-0004km-00; Fri, 10 Oct 2003 11:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ys4-0001DB-Nt; Fri, 10 Oct 2003 11:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yrQ-00012u-33 for simple@optimus.ietf.org; Fri, 10 Oct 2003 11:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02415 for ; Fri, 10 Oct 2003 11:07:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yrN-0004j6-00 for simple@ietf.org; Fri, 10 Oct 2003 11:07:17 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7yrM-0004j2-00 for simple@ietf.org; Fri, 10 Oct 2003 11:07:16 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AF6teY099362; Fri, 10 Oct 2003 10:07:02 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F86CB03.5000908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 10:06:43 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, October 10, 2003 5:36 PM >>To: Paul Kyzivat >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >>simple@ietf.org >>Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >>I had originally read Hisham's suggestion as having the relay >>wait for >>up to a full inactivity timeout between the time it stops >>allowing SEND >>and the time it drops the connections. Assuming this timer >>value is 10 >>(or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > > > No, I suggested that either the relay waits the full timeout, or until it know it has sent 4xx (or 5xx) response to SEND requests sent by all the participants in all session. Whichever is reached first. That is not far from the same thing, since if there was a single idle session, it will take up to 1 timeout for each endpoint to send a request that the relay could respond to. But my point was, for Paul's scenario, it is not neccessary to wait for idle endpoints to get around to sending a request. You just have to wait long enough so that it is very unlikely that any transactions are still in play. A small number of minutes should be plenty of time. > > Regards, > Hisham > > >>But in the case you mention, a full timeout would not be >>needed. Rather, >>just waiting a reasonable time to make sure that there are no SEND >>transactions in play would be sufficient. Is that what you >>had in mind? >>If so, I don't have a problem putting in as a SHOULD strength. >> >>Does anyone have thoughts on an appropriate response code for >>this? We >>already have 481 for no session, which seems borderline >>appropriate. We >>also have 500 which means "unable to forward SEND request" which is >>exactly the case but could be a little too generic. Is there a case >>where a client would handle a 500 different than some 5xx "relay >>shutting down" response? >> >> >> >> >> >>Paul Kyzivat wrote: >> >> >>>What Hisham says sounds good to me. >>> >>>I'm trying to think of a scenario where this makes a >> >>difference. I think >> >>>I have one: >>> >>>Suppose there is an MSRP session between A and B, and >> >>involving a relay >> >>>R1. Some administrator wants to shut down R1. This doesn't >> >>mean that A >> >>>and B want to stop chatting. When the relay goes down, the chat >>>applications will probably want to attempt renegotiation of >> >>the session, >> >>>via a reINVITE. >>> >>>Assuming they can find a substitute relay, this should work ok. But >>>there is of course the question of messages already sent: >> >>have they been >> >>>delivered, or should they be sent again? If they are sent >> >>again, the >> >>>recipient may see the same message appear twice. >>> >>>If the connection is just torn down (option 2) then A and B >> >>have no way >> >>>of knowing whether the message outstanding were received, >> >>and so will >> >>>have to assume no and retransmit. If option 1 is used, then the >>>connection will go down smoothly and there will be no >> >>question, so no >> >>>repeated messages. >>> >>> Paul >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>Does a 400 response for a SEND request terminate the MSRP >> >>session? If >> >>>>so, then option 1 (or a variant thereof) would be simple enough: A >>>>Relay refuses all SEND requests, once it has done so for every >>>>connection, it can assume all sessions are done and shut down. >>>> >>>>Of course option 2 is much SIMPLEr. >>>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>>Sent: Thursday, October 09, 2003 4:26 PM >>>>>To: Khartabil Hisham (NMP-MSW/Helsinki); >> >>bcampbell@dynamicsoft.com; >> >>>>>simple@ietf.org >>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> >>>>>The only benefit I can see from using option 1 would be that an >>>>>appropriate response/reason phrase to the SEND requests >> >>would allow a >> >>>>>more graceful shutdown of sessions in an endpoint (The >> >>host of this >> >>>>>session is terminating so I must dispose of the MSRP >> >>session) BUT I also >> >>>>>see that option 2 keeps it SIMPLE ;-). >>>>> >>>>>Chris. >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: hisham.khartabil@nokia.com >> >>[mailto:hisham.khartabil@nokia.com] >> >>>>>>Sent: 09 October 2003 14:13 >>>>>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>>> >>>>>>I vote for option 2. >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>>>Sent: Wednesday, October 08, 2003 11:44 PM >>>>>>>To: simple@ietf.org >>>>>>>Subject: [Simple] MSRP: Administrative shutdown of relays >>>>>>> >>>>>>> >>>>>>>I just realized that we had one more subject brought up in >>>>>>>Vienna where >>>>>>>we decided to "take it to the list". Which of course has not >>>>>>>yet happened. >>>>>>> >>>>>>>The question was brought up that, in the previous version of >>>>>>>MSRP where >>>>>>>we refreshed state with BIND and VISIT, we had an implied >>>>>>>mechanism by >>>>>>>which a relay could shed load for shutdown. That is, is >>>>>>>starts refusing >>>>>>>refreshes until all sessions have expired. >>>>>>> >>>>>>>Since we have moved to a keep-alive approach rather than >>>>>> >>>>>> >>>>>the refresh >>>>> >>>>> >>>>>>>approach, this is not as clean. A couple of approaches >>>>>> >>>>>> >>>>>come to mind: >>>>> >>>>> >>>>>>>1) Start refusing _any_ SEND requests, then assume all the >>>>>>>sessions are >>>>>>>gone when the timeout period expires. >>>>>>> >>>>>>>2) Just close all TCP connections and let the endpoints >>>>>> >>>>>> >>>>>deal with it. >>>>> >>>>> >>>>>>>I find myself leaning toward 2, as 1 does not allow the >>>>>>>endpoints to do >>>>>>>anything useful on the session anyway. >>>>>>> >>>>>>>Thoughts? >>>>>>> >>>>>>>Ben. >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Simple mailing list >>>>>>>Simple@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 11:17:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03049; Fri, 10 Oct 2003 11:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7z0u-0004wp-00; Fri, 10 Oct 2003 11:17:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7z0u-0004wm-00; Fri, 10 Oct 2003 11:17:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7z0o-0001uH-1F; Fri, 10 Oct 2003 11:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7z0n-0001tr-4A for simple@optimus.ietf.org; Fri, 10 Oct 2003 11:17:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03037 for ; Fri, 10 Oct 2003 11:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7z0l-0004wV-00 for simple@ietf.org; Fri, 10 Oct 2003 11:16:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7z0k-0004wP-00 for simple@ietf.org; Fri, 10 Oct 2003 11:16:58 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AFGseY000736; Fri, 10 Oct 2003 10:16:55 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F86CD5A.4080309@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Overload (was MSRP: Administrative shutdown of relays) References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> <1065797156.981.32.camel@RjS.localdomain> In-Reply-To: <1065797156.981.32.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 10:16:42 -0500 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > (as not-the-chair): > > It occurs to me that we have another scenario that deserves exploration. > What do we have a relay do when it reaches capacity? > > Rejecting new binds is obvious, but what do we do when traffic on > existing sessions begins to overwhelm the relay? Beginning to terminate > some of them by 481ing selected SENDs would help, but that would likely > result in an immediate reattempt to BIND (along with a TCP connect). > Do we want to avoid that and have some way to say "Go away and don't > bother me again until x amount of time has passed"? We could add something like a retry-after. But would it be enough to have the relay simply stop accepting binds _and_ send some 481s? Maybe even stop listening for new TCP connections entirely? > > RjS > > On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > >>I had originally read Hisham's suggestion as having the relay wait for >>up to a full inactivity timeout between the time it stops allowing SEND >>and the time it drops the connections. Assuming this timer value is 10 >>(or 12 for Adam :-) ) minutes, this seemed like an excessive burden. >> >>But in the case you mention, a full timeout would not be needed. Rather, >>just waiting a reasonable time to make sure that there are no SEND >>transactions in play would be sufficient. Is that what you had in mind? >>If so, I don't have a problem putting in as a SHOULD strength. >> >>Does anyone have thoughts on an appropriate response code for this? We >>already have 481 for no session, which seems borderline appropriate. We >>also have 500 which means "unable to forward SEND request" which is >>exactly the case but could be a little too generic. Is there a case >>where a client would handle a 500 different than some 5xx "relay >>shutting down" response? >> >> >> >> >> >>Paul Kyzivat wrote: >> >> >>>What Hisham says sounds good to me. >>> >>>I'm trying to think of a scenario where this makes a difference. I think >>>I have one: >>> >>>Suppose there is an MSRP session between A and B, and involving a relay >>>R1. Some administrator wants to shut down R1. This doesn't mean that A >>>and B want to stop chatting. When the relay goes down, the chat >>>applications will probably want to attempt renegotiation of the session, >>>via a reINVITE. >>> >>>Assuming they can find a substitute relay, this should work ok. But >>>there is of course the question of messages already sent: have they been >>>delivered, or should they be sent again? If they are sent again, the >>>recipient may see the same message appear twice. >>> >>>If the connection is just torn down (option 2) then A and B have no way >>>of knowing whether the message outstanding were received, and so will >>>have to assume no and retransmit. If option 1 is used, then the >>>connection will go down smoothly and there will be no question, so no >>>repeated messages. >>> >>> Paul >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>Does a 400 response for a SEND request terminate the MSRP session? If >>>>so, then option 1 (or a variant thereof) would be simple enough: A >>>>Relay refuses all SEND requests, once it has done so for every >>>>connection, it can assume all sessions are done and shut down. >>>> >>>>Of course option 2 is much SIMPLEr. >>>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>>Sent: Thursday, October 09, 2003 4:26 PM >>>>>To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>>>>simple@ietf.org >>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> >>>>>The only benefit I can see from using option 1 would be that an >>>>>appropriate response/reason phrase to the SEND requests would allow a >>>>>more graceful shutdown of sessions in an endpoint (The host of this >>>>>session is terminating so I must dispose of the MSRP session) BUT I also >>>>>see that option 2 keeps it SIMPLE ;-). >>>>> >>>>>Chris. >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>>>Sent: 09 October 2003 14:13 >>>>>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>>> >>>>>>I vote for option 2. >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>>>Sent: Wednesday, October 08, 2003 11:44 PM >>>>>>>To: simple@ietf.org >>>>>>>Subject: [Simple] MSRP: Administrative shutdown of relays >>>>>>> >>>>>>> >>>>>>>I just realized that we had one more subject brought up in >>>>>>>Vienna where >>>>>>>we decided to "take it to the list". Which of course has not >>>>>>>yet happened. >>>>>>> >>>>>>>The question was brought up that, in the previous version of >>>>>>>MSRP where >>>>>>>we refreshed state with BIND and VISIT, we had an implied >>>>>>>mechanism by >>>>>>>which a relay could shed load for shutdown. That is, is >>>>>>>starts refusing >>>>>>>refreshes until all sessions have expired. >>>>>>> >>>>>>>Since we have moved to a keep-alive approach rather than >>>>>> >>>>>> >>>>>the refresh >>>>> >>>>> >>>>>>>approach, this is not as clean. A couple of approaches >>>>>> >>>>>> >>>>>come to mind: >>>>> >>>>> >>>>>>>1) Start refusing _any_ SEND requests, then assume all the >>>>>>>sessions are >>>>>>>gone when the timeout period expires. >>>>>>> >>>>>>>2) Just close all TCP connections and let the endpoints >>>>>> >>>>>> >>>>>deal with it. >>>>> >>>>> >>>>>>>I find myself leaning toward 2, as 1 does not allow the >>>>>>>endpoints to do >>>>>>>anything useful on the session anyway. >>>>>>> >>>>>>>Thoughts? >>>>>>> >>>>>>>Ben. >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Simple mailing list >>>>>>>Simple@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 11:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03085 for ; Fri, 10 Oct 2003 11:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7z0w-0001xE-3l for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 11:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AFHAPg007499 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 11:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7z0v-0001ws-U5 for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 11:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03049; Fri, 10 Oct 2003 11:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7z0u-0004wp-00; Fri, 10 Oct 2003 11:17:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7z0u-0004wm-00; Fri, 10 Oct 2003 11:17:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7z0o-0001uH-1F; Fri, 10 Oct 2003 11:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7z0n-0001tr-4A for simple@optimus.ietf.org; Fri, 10 Oct 2003 11:17:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03037 for ; Fri, 10 Oct 2003 11:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7z0l-0004wV-00 for simple@ietf.org; Fri, 10 Oct 2003 11:16:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A7z0k-0004wP-00 for simple@ietf.org; Fri, 10 Oct 2003 11:16:58 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AFGseY000736; Fri, 10 Oct 2003 10:16:55 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F86CD5A.4080309@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Overload (was MSRP: Administrative shutdown of relays) References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> <1065797156.981.32.camel@RjS.localdomain> In-Reply-To: <1065797156.981.32.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 10:16:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > (as not-the-chair): > > It occurs to me that we have another scenario that deserves exploration. > What do we have a relay do when it reaches capacity? > > Rejecting new binds is obvious, but what do we do when traffic on > existing sessions begins to overwhelm the relay? Beginning to terminate > some of them by 481ing selected SENDs would help, but that would likely > result in an immediate reattempt to BIND (along with a TCP connect). > Do we want to avoid that and have some way to say "Go away and don't > bother me again until x amount of time has passed"? We could add something like a retry-after. But would it be enough to have the relay simply stop accepting binds _and_ send some 481s? Maybe even stop listening for new TCP connections entirely? > > RjS > > On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > >>I had originally read Hisham's suggestion as having the relay wait for >>up to a full inactivity timeout between the time it stops allowing SEND >>and the time it drops the connections. Assuming this timer value is 10 >>(or 12 for Adam :-) ) minutes, this seemed like an excessive burden. >> >>But in the case you mention, a full timeout would not be needed. Rather, >>just waiting a reasonable time to make sure that there are no SEND >>transactions in play would be sufficient. Is that what you had in mind? >>If so, I don't have a problem putting in as a SHOULD strength. >> >>Does anyone have thoughts on an appropriate response code for this? We >>already have 481 for no session, which seems borderline appropriate. We >>also have 500 which means "unable to forward SEND request" which is >>exactly the case but could be a little too generic. Is there a case >>where a client would handle a 500 different than some 5xx "relay >>shutting down" response? >> >> >> >> >> >>Paul Kyzivat wrote: >> >> >>>What Hisham says sounds good to me. >>> >>>I'm trying to think of a scenario where this makes a difference. I think >>>I have one: >>> >>>Suppose there is an MSRP session between A and B, and involving a relay >>>R1. Some administrator wants to shut down R1. This doesn't mean that A >>>and B want to stop chatting. When the relay goes down, the chat >>>applications will probably want to attempt renegotiation of the session, >>>via a reINVITE. >>> >>>Assuming they can find a substitute relay, this should work ok. But >>>there is of course the question of messages already sent: have they been >>>delivered, or should they be sent again? If they are sent again, the >>>recipient may see the same message appear twice. >>> >>>If the connection is just torn down (option 2) then A and B have no way >>>of knowing whether the message outstanding were received, and so will >>>have to assume no and retransmit. If option 1 is used, then the >>>connection will go down smoothly and there will be no question, so no >>>repeated messages. >>> >>> Paul >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>Does a 400 response for a SEND request terminate the MSRP session? If >>>>so, then option 1 (or a variant thereof) would be simple enough: A >>>>Relay refuses all SEND requests, once it has done so for every >>>>connection, it can assume all sessions are done and shut down. >>>> >>>>Of course option 2 is much SIMPLEr. >>>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>>Sent: Thursday, October 09, 2003 4:26 PM >>>>>To: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>>>>simple@ietf.org >>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>> >>>>> >>>>>The only benefit I can see from using option 1 would be that an >>>>>appropriate response/reason phrase to the SEND requests would allow a >>>>>more graceful shutdown of sessions in an endpoint (The host of this >>>>>session is terminating so I must dispose of the MSRP session) BUT I also >>>>>see that option 2 keeps it SIMPLE ;-). >>>>> >>>>>Chris. >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>>>Sent: 09 October 2003 14:13 >>>>>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>>Subject: RE: [Simple] MSRP: Administrative shutdown of relays >>>>>> >>>>>>I vote for option 2. >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>>>Sent: Wednesday, October 08, 2003 11:44 PM >>>>>>>To: simple@ietf.org >>>>>>>Subject: [Simple] MSRP: Administrative shutdown of relays >>>>>>> >>>>>>> >>>>>>>I just realized that we had one more subject brought up in >>>>>>>Vienna where >>>>>>>we decided to "take it to the list". Which of course has not >>>>>>>yet happened. >>>>>>> >>>>>>>The question was brought up that, in the previous version of >>>>>>>MSRP where >>>>>>>we refreshed state with BIND and VISIT, we had an implied >>>>>>>mechanism by >>>>>>>which a relay could shed load for shutdown. That is, is >>>>>>>starts refusing >>>>>>>refreshes until all sessions have expired. >>>>>>> >>>>>>>Since we have moved to a keep-alive approach rather than >>>>>> >>>>>> >>>>>the refresh >>>>> >>>>> >>>>>>>approach, this is not as clean. A couple of approaches >>>>>> >>>>>> >>>>>come to mind: >>>>> >>>>> >>>>>>>1) Start refusing _any_ SEND requests, then assume all the >>>>>>>sessions are >>>>>>>gone when the timeout period expires. >>>>>>> >>>>>>>2) Just close all TCP connections and let the endpoints >>>>>> >>>>>> >>>>>deal with it. >>>>> >>>>> >>>>>>>I find myself leaning toward 2, as 1 does not allow the >>>>>>>endpoints to do >>>>>>>anything useful on the session anyway. >>>>>>> >>>>>>>Thoughts? >>>>>>> >>>>>>>Ben. >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Simple mailing list >>>>>>>Simple@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 12:03:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04779; Fri, 10 Oct 2003 12:03:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zjc-0005Wf-00; Fri, 10 Oct 2003 12:03:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zjc-0005Wb-00; Fri, 10 Oct 2003 12:03:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zjK-0004oH-9H; Fri, 10 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zj3-0004nd-9c for simple@optimus.ietf.org; Fri, 10 Oct 2003 12:02:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04750 for ; Fri, 10 Oct 2003 12:02:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zj1-0005Vx-00 for simple@ietf.org; Fri, 10 Oct 2003 12:02:43 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1A7zj0-0005VW-00 for simple@ietf.org; Fri, 10 Oct 2003 12:02:42 -0400 Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AG1wTu016971 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Oct 2003 11:01:58 -0500 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9AG1wmr016969; Fri, 10 Oct 2003 11:01:58 -0500 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Simple] Overload (was MSRP: Administrative shutdown of relays) From: Dean Willis To: Robert Sparks Cc: simple@ietf.org In-Reply-To: <1065797156.981.32.camel@RjS.localdomain> References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> <1065797156.981.32.camel@RjS.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065801718.16639.41.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 11:01:58 -0500 Content-Transfer-Encoding: 7bit On Fri, 2003-10-10 at 09:45, Robert Sparks wrote: > (as not-the-chair): > > It occurs to me that we have another scenario that deserves exploration. > What do we have a relay do when it reaches capacity? > > Rejecting new binds is obvious, but what do we do when traffic on > existing sessions begins to overwhelm the relay? Beginning to terminate > some of them by 481ing selected SENDs would help, but that would likely > result in an immediate reattempt to BIND (along with a TCP connect). > Do we want to avoid that and have some way to say "Go away and don't > bother me again until x amount of time has passed"? > Remember when I predicted that we were going to end up with an almost-exact replica of SIP and might as well just use MESSAGE? Just checking. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 12:03:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04814 for ; Fri, 10 Oct 2003 12:03:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zjq-0004rw-W0 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 12:03:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AG3Yp4018710 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 12:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zjq-0004rh-Rg for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:03:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04779; Fri, 10 Oct 2003 12:03:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zjc-0005Wf-00; Fri, 10 Oct 2003 12:03:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zjc-0005Wb-00; Fri, 10 Oct 2003 12:03:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zjK-0004oH-9H; Fri, 10 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zj3-0004nd-9c for simple@optimus.ietf.org; Fri, 10 Oct 2003 12:02:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04750 for ; Fri, 10 Oct 2003 12:02:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zj1-0005Vx-00 for simple@ietf.org; Fri, 10 Oct 2003 12:02:43 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1A7zj0-0005VW-00 for simple@ietf.org; Fri, 10 Oct 2003 12:02:42 -0400 Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AG1wTu016971 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Oct 2003 11:01:58 -0500 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9AG1wmr016969; Fri, 10 Oct 2003 11:01:58 -0500 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Simple] Overload (was MSRP: Administrative shutdown of relays) From: Dean Willis To: Robert Sparks Cc: simple@ietf.org In-Reply-To: <1065797156.981.32.camel@RjS.localdomain> References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> <1065797156.981.32.camel@RjS.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065801718.16639.41.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 11:01:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2003-10-10 at 09:45, Robert Sparks wrote: > (as not-the-chair): > > It occurs to me that we have another scenario that deserves exploration. > What do we have a relay do when it reaches capacity? > > Rejecting new binds is obvious, but what do we do when traffic on > existing sessions begins to overwhelm the relay? Beginning to terminate > some of them by 481ing selected SENDs would help, but that would likely > result in an immediate reattempt to BIND (along with a TCP connect). > Do we want to avoid that and have some way to say "Go away and don't > bother me again until x amount of time has passed"? > Remember when I predicted that we were going to end up with an almost-exact replica of SIP and might as well just use MESSAGE? Just checking. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 12:20:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05490; Fri, 10 Oct 2003 12:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zzr-0005mc-00; Fri, 10 Oct 2003 12:20:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zzr-0005mZ-00; Fri, 10 Oct 2003 12:20:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zzm-0006lo-Ih; Fri, 10 Oct 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zzd-0006l9-9o for simple@optimus.ietf.org; Fri, 10 Oct 2003 12:19:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05484 for ; Fri, 10 Oct 2003 12:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zzb-0005mO-00 for simple@ietf.org; Fri, 10 Oct 2003 12:19:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7zza-0005m8-00 for simple@ietf.org; Fri, 10 Oct 2003 12:19:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9AGJHd23833; Fri, 10 Oct 2003 11:19:17 -0500 Subject: Re: [Simple] Overload (was MSRP: Administrative shutdown of relays) From: Robert Sparks To: Dean Willis Cc: simple@ietf.org In-Reply-To: <1065801718.16639.41.camel@bdsl.greycouncil.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> <1065797156.981.32.camel@RjS.localdomain> <1065801718.16639.41.camel@bdsl.greycouncil.com> Content-Type: text/plain Message-Id: <1065802755.937.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 11:19:15 -0500 Content-Transfer-Encoding: 7bit I'm not suggesting mimicking SIPs 503/Retry-After - its granularity is too coarse. There are other approaches we could look at (like the way sendmail quits accepting connections when it gets resource constrained. But, I would like to know if the working group thinks exploring this functionality is warranted before diving any deeper into the mechanism though. RjS On Fri, 2003-10-10 at 11:01, Dean Willis wrote: > On Fri, 2003-10-10 at 09:45, Robert Sparks wrote: > > (as not-the-chair): > > > > It occurs to me that we have another scenario that deserves exploration. > > What do we have a relay do when it reaches capacity? > > > > Rejecting new binds is obvious, but what do we do when traffic on > > existing sessions begins to overwhelm the relay? Beginning to terminate > > some of them by 481ing selected SENDs would help, but that would likely > > result in an immediate reattempt to BIND (along with a TCP connect). > > Do we want to avoid that and have some way to say "Go away and don't > > bother me again until x amount of time has passed"? > > > > Remember when I predicted that we were going to end up with an > almost-exact replica of SIP and might as well just use MESSAGE? > > Just checking. > > -- > Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 12:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05521 for ; Fri, 10 Oct 2003 12:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zzu-0006nL-4Y for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 12:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGKAZG026103 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 12:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zzt-0006mw-W9 for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:20:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05490; Fri, 10 Oct 2003 12:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zzr-0005mc-00; Fri, 10 Oct 2003 12:20:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zzr-0005mZ-00; Fri, 10 Oct 2003 12:20:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zzm-0006lo-Ih; Fri, 10 Oct 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zzd-0006l9-9o for simple@optimus.ietf.org; Fri, 10 Oct 2003 12:19:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05484 for ; Fri, 10 Oct 2003 12:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zzb-0005mO-00 for simple@ietf.org; Fri, 10 Oct 2003 12:19:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7zza-0005m8-00 for simple@ietf.org; Fri, 10 Oct 2003 12:19:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9AGJHd23833; Fri, 10 Oct 2003 11:19:17 -0500 Subject: Re: [Simple] Overload (was MSRP: Administrative shutdown of relays) From: Robert Sparks To: Dean Willis Cc: simple@ietf.org In-Reply-To: <1065801718.16639.41.camel@bdsl.greycouncil.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797218@esebe019.ntc.nokia.com> <3F86A93B.1090102@cisco.com> <3F86C3B5.5010803@dynamicsoft.com> <1065797156.981.32.camel@RjS.localdomain> <1065801718.16639.41.camel@bdsl.greycouncil.com> Content-Type: text/plain Message-Id: <1065802755.937.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 11:19:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm not suggesting mimicking SIPs 503/Retry-After - its granularity is too coarse. There are other approaches we could look at (like the way sendmail quits accepting connections when it gets resource constrained. But, I would like to know if the working group thinks exploring this functionality is warranted before diving any deeper into the mechanism though. RjS On Fri, 2003-10-10 at 11:01, Dean Willis wrote: > On Fri, 2003-10-10 at 09:45, Robert Sparks wrote: > > (as not-the-chair): > > > > It occurs to me that we have another scenario that deserves exploration. > > What do we have a relay do when it reaches capacity? > > > > Rejecting new binds is obvious, but what do we do when traffic on > > existing sessions begins to overwhelm the relay? Beginning to terminate > > some of them by 481ing selected SENDs would help, but that would likely > > result in an immediate reattempt to BIND (along with a TCP connect). > > Do we want to avoid that and have some way to say "Go away and don't > > bother me again until x amount of time has passed"? > > > > Remember when I predicted that we were going to end up with an > almost-exact replica of SIP and might as well just use MESSAGE? > > Just checking. > > -- > Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 16:14:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19844; Fri, 10 Oct 2003 16:14:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83eJ-0001lv-00; Fri, 10 Oct 2003 16:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83eI-0001ls-00; Fri, 10 Oct 2003 16:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83eD-0000qq-In; Fri, 10 Oct 2003 16:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83dN-0000pI-6f for simple@optimus.ietf.org; Fri, 10 Oct 2003 16:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19669 for ; Fri, 10 Oct 2003 16:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83dL-0001j4-00 for simple@ietf.org; Fri, 10 Oct 2003 16:13:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A83dK-0001hH-00 for simple@ietf.org; Fri, 10 Oct 2003 16:13:06 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 13:21:10 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9AKCRXg016103; Fri, 10 Oct 2003 13:12:27 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB31896; Fri, 10 Oct 2003 16:12:26 -0400 (EDT) Message-ID: <3F8712AA.7010505@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> <3F86CB03.5000908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 16:12:26 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > That is not far from the same thing, since if there was a single idle > session, it will take up to 1 timeout for each endpoint to send a > request that the relay could respond to. > > But my point was, for Paul's scenario, it is not neccessary to wait for > idle endpoints to get around to sending a request. You just have to wait > long enough so that it is very unlikely that any transactions are still > in play. A small number of minutes should be plenty of time. Hmm. How does waiting decrease the likelihood that messages are still in play? Even though there have been no messages in the last N minutes, one could just have been sent. To be sure there are none, I think you must in general wait for the timeout interval if the stream is idle. But if the stream is active, you can just start sending the magic error code to every received message for awhile, with the understanding that a sending, upon receiving this code, will no longer send messages on the stream. Then, after enough time has passed for all messages in the pipeline to have been received, then stream can be shutdown. To speed up shutdown of an inactive stream I think either the inactivity timeout needs to be reduced, or else there needs to be a special graceful close message that can be sent. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 16:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19914 for ; Fri, 10 Oct 2003 16:14:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83eL-0000rt-Tj for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 16:14:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKE9Pq003333 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 16:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83eL-0000rg-QQ for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 16:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19844; Fri, 10 Oct 2003 16:14:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83eJ-0001lv-00; Fri, 10 Oct 2003 16:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83eI-0001ls-00; Fri, 10 Oct 2003 16:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83eD-0000qq-In; Fri, 10 Oct 2003 16:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83dN-0000pI-6f for simple@optimus.ietf.org; Fri, 10 Oct 2003 16:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19669 for ; Fri, 10 Oct 2003 16:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83dL-0001j4-00 for simple@ietf.org; Fri, 10 Oct 2003 16:13:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A83dK-0001hH-00 for simple@ietf.org; Fri, 10 Oct 2003 16:13:06 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 13:21:10 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9AKCRXg016103; Fri, 10 Oct 2003 13:12:27 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB31896; Fri, 10 Oct 2003 16:12:26 -0400 (EDT) Message-ID: <3F8712AA.7010505@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> <3F86CB03.5000908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 16:12:26 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > That is not far from the same thing, since if there was a single idle > session, it will take up to 1 timeout for each endpoint to send a > request that the relay could respond to. > > But my point was, for Paul's scenario, it is not neccessary to wait for > idle endpoints to get around to sending a request. You just have to wait > long enough so that it is very unlikely that any transactions are still > in play. A small number of minutes should be plenty of time. Hmm. How does waiting decrease the likelihood that messages are still in play? Even though there have been no messages in the last N minutes, one could just have been sent. To be sure there are none, I think you must in general wait for the timeout interval if the stream is idle. But if the stream is active, you can just start sending the magic error code to every received message for awhile, with the understanding that a sending, upon receiving this code, will no longer send messages on the stream. Then, after enough time has passed for all messages in the pipeline to have been received, then stream can be shutdown. To speed up shutdown of an inactive stream I think either the inactivity timeout needs to be reduced, or else there needs to be a special graceful close message that can be sent. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 10 16:48:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22269; Fri, 10 Oct 2003 16:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84BH-0002Wq-00; Fri, 10 Oct 2003 16:48:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A84BH-0002Wn-00; Fri, 10 Oct 2003 16:48:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84B7-0003Uc-Nh; Fri, 10 Oct 2003 16:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84Ax-0003UH-SU for simple@optimus.ietf.org; Fri, 10 Oct 2003 16:47:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22254 for ; Fri, 10 Oct 2003 16:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84Av-0002Wb-00 for simple@ietf.org; Fri, 10 Oct 2003 16:47:49 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A84Au-0002WL-00 for simple@ietf.org; Fri, 10 Oct 2003 16:47:48 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AKlSeY029150; Fri, 10 Oct 2003 15:47:35 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F871AD2.6000103@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> <3F86CB03.5000908@dynamicsoft.com> <3F8712AA.7010505@cisco.com> In-Reply-To: <3F8712AA.7010505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 15:47:14 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> That is not far from the same thing, since if there was a single idle >> session, it will take up to 1 timeout for each endpoint to send a >> request that the relay could respond to. >> >> But my point was, for Paul's scenario, it is not neccessary to wait >> for idle endpoints to get around to sending a request. You just have >> to wait long enough so that it is very unlikely that any transactions >> are still in play. A small number of minutes should be plenty of time. > > > Hmm. How does waiting decrease the likelihood that messages are still in > play? Even though there have been no messages in the last N minutes, one > could just have been sent. > > To be sure there are none, I think you must in general wait for the > timeout interval if the stream is idle. But if the stream is active, you > can just start sending the magic error code to every received message > for awhile, with the understanding that a sending, upon receiving this > code, will no longer send messages on the stream. Then, after enough > time has passed for all messages in the pipeline to have been received, > then stream can be shutdown. If the goal is to make the relay notifies all endpoints prior to shutting down, then yes, you would have to wait for a full inactivity timeout period. But that was not the scenario you subscribed. If the relay begins sending 500 responses to any message at time T, then it can assume that there are no more outstanding transactions at T+N. Where N is the _transaction_ timout, rather than the inactivity timeout. (Now, we do not actually define the transaction timeout--it is currently listed as some "reasonable period of time." Maybe we need to specify that, but I am not sure this particular reason is enough to force that issue.) So, at time T+N, the relay can reasonably assume that any transaction that was already in progress when it started sending the 500s has either completed or timed out. I suppose there could be requests that are still sitting in the endpoints TCP send buffer and never get a 500, but that would be a pretty small percentages of messages overall. > > To speed up shutdown of an inactive stream I think either the inactivity > timeout needs to be reduced, or else there needs to be a special > graceful close message that can be sent. I gather that you are looking for a "perfectly" graceful shutdown, that guarantees that the endpoint will know for sure that a given message has been delivered or not delivered. I accept that it may be polite behavior to minimize messages in "limbo". But nothing in MSRP guarantees that a SEND transaction that times out without a response has not actually been delivered. We can only guarantee that, if you get a successful response back, the message _has_ been delivered. So I think it is reasonable to suggest that a relay wait a couple of minutes after it stops relaying requests before it actually shuts down. I don't think it is reasonable to ask it to wait 12 minutes, and I don't think that this particular issue provides sufficient motivation to reduce the idle timer. What do others think on this point? > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 10 16:48:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22292 for ; Fri, 10 Oct 2003 16:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84BK-0003YV-KG for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 16:48:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKmEop013661 for simple-archive@odin.ietf.org; Fri, 10 Oct 2003 16:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84BK-0003YG-H4 for simple-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 16:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22269; Fri, 10 Oct 2003 16:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84BH-0002Wq-00; Fri, 10 Oct 2003 16:48:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A84BH-0002Wn-00; Fri, 10 Oct 2003 16:48:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84B7-0003Uc-Nh; Fri, 10 Oct 2003 16:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84Ax-0003UH-SU for simple@optimus.ietf.org; Fri, 10 Oct 2003 16:47:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22254 for ; Fri, 10 Oct 2003 16:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84Av-0002Wb-00 for simple@ietf.org; Fri, 10 Oct 2003 16:47:49 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A84Au-0002WL-00 for simple@ietf.org; Fri, 10 Oct 2003 16:47:48 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9AKlSeY029150; Fri, 10 Oct 2003 15:47:35 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F871AD2.6000103@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723A@esebe019.ntc.nokia.com> <3F86CB03.5000908@dynamicsoft.com> <3F8712AA.7010505@cisco.com> In-Reply-To: <3F8712AA.7010505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 15:47:14 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> That is not far from the same thing, since if there was a single idle >> session, it will take up to 1 timeout for each endpoint to send a >> request that the relay could respond to. >> >> But my point was, for Paul's scenario, it is not neccessary to wait >> for idle endpoints to get around to sending a request. You just have >> to wait long enough so that it is very unlikely that any transactions >> are still in play. A small number of minutes should be plenty of time. > > > Hmm. How does waiting decrease the likelihood that messages are still in > play? Even though there have been no messages in the last N minutes, one > could just have been sent. > > To be sure there are none, I think you must in general wait for the > timeout interval if the stream is idle. But if the stream is active, you > can just start sending the magic error code to every received message > for awhile, with the understanding that a sending, upon receiving this > code, will no longer send messages on the stream. Then, after enough > time has passed for all messages in the pipeline to have been received, > then stream can be shutdown. If the goal is to make the relay notifies all endpoints prior to shutting down, then yes, you would have to wait for a full inactivity timeout period. But that was not the scenario you subscribed. If the relay begins sending 500 responses to any message at time T, then it can assume that there are no more outstanding transactions at T+N. Where N is the _transaction_ timout, rather than the inactivity timeout. (Now, we do not actually define the transaction timeout--it is currently listed as some "reasonable period of time." Maybe we need to specify that, but I am not sure this particular reason is enough to force that issue.) So, at time T+N, the relay can reasonably assume that any transaction that was already in progress when it started sending the 500s has either completed or timed out. I suppose there could be requests that are still sitting in the endpoints TCP send buffer and never get a 500, but that would be a pretty small percentages of messages overall. > > To speed up shutdown of an inactive stream I think either the inactivity > timeout needs to be reduced, or else there needs to be a special > graceful close message that can be sent. I gather that you are looking for a "perfectly" graceful shutdown, that guarantees that the endpoint will know for sure that a given message has been delivered or not delivered. I accept that it may be polite behavior to minimize messages in "limbo". But nothing in MSRP guarantees that a SEND transaction that times out without a response has not actually been delivered. We can only guarantee that, if you get a successful response back, the message _has_ been delivered. So I think it is reasonable to suggest that a relay wait a couple of minutes after it stops relaying requests before it actually shuts down. I don't think it is reasonable to ask it to wait 12 minutes, and I don't think that this particular issue provides sufficient motivation to reduce the idle timer. What do others think on this point? > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Oct 11 03:43:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24897; Sat, 11 Oct 2003 03:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EPE-0001fc-00; Sat, 11 Oct 2003 03:43:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8EPE-0001f6-00; Sat, 11 Oct 2003 03:43:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EOz-0007en-7t; Sat, 11 Oct 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EOa-0007dM-V4 for simple@optimus.ietf.org; Sat, 11 Oct 2003 03:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24886 for ; Sat, 11 Oct 2003 03:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EOY-0001eu-00 for simple@ietf.org; Sat, 11 Oct 2003 03:42:34 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A8EOX-0001eg-00 for simple@ietf.org; Sat, 11 Oct 2003 03:42:33 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9B7fwO8018450; Sat, 11 Oct 2003 02:41:58 -0500 (CDT) Received: from ericsson.com (fijowa02m28.sw.ericsson.se [136.225.183.92]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCLR8F; Sat, 11 Oct 2003 02:41:22 -0500 Message-ID: <3F87B441.5050604@ericsson.com> X-Sybari-Trust: 446b27e0 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <2038BCC78B1AD641891A0D1AE133DBB701797217@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797217@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Oct 2003 10:41:53 +0300 Content-Transfer-Encoding: 7bit I am pretty sure that the final solution would be based on the work on the configuration/policies that is taking place in SIPPING. /Miguel hisham.khartabil@nokia.com wrote: > How about UA configuration from SIPPING (or any other configuration protocol)? > > /Hisham > > >>-----Original Message----- >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: Thursday, October 09, 2003 2:03 AM >>To: Adam Roach >>Cc: Jonathan Rosenberg; simple@ietf.org >>Subject: Re: [Simple] Discovery of an MSRP relay >> >> >>Adam: >> >>Your proposal works if I am in my home network. But if I am >>roaming, the >>DHCP server will be located in the roaming network, and will be >>provisioned with information about the MSRP relay in the roaming >>network. If this is the case, fine, it will work, but if by policy, I >>have to use the MSRP provided in my home network, and I am >>roaming, it >>won't work. Further more, if the roaming network does not >>offer an MSRP >>relay service, but my home network does, I won't be able to >>discover the >>MSRP relay server. >> >>I am not sure, at this stage, which of the above cases would >>be the case >>for MSRP relays... I just want to be prepared with solutions >>that solve >>any of the possible requirements. >> >>/Miguel >> >>Adam Roach wrote: >> >> >>>Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: >>> >>> >>> >>>>In another case, an MSRP relay is provided in a home network, >>>>and that MSRP relay is used no matter whether the user is >>>>attached directly to such network or indirectly through other >>>>networks. In this case DHCP won't obviously solve the problem. >>> >>> >>>For this case, I suggest we borrow a page from the well-understood, >>>time-tested, universally deployed, and demonstrably workable >>>mechanism that HTTP clients use to solve the problem of finding >>>HTTP proxies. >>> >>>/a >> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Oct 11 03:43:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24943 for ; Sat, 11 Oct 2003 03:43:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EPI-0007hP-0v for simple-archive@odin.ietf.org; Sat, 11 Oct 2003 03:43:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B7hJvx029592 for simple-archive@odin.ietf.org; Sat, 11 Oct 2003 03:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EPH-0007hD-Kc for simple-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 03:43:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24897; Sat, 11 Oct 2003 03:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EPE-0001fc-00; Sat, 11 Oct 2003 03:43:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8EPE-0001f6-00; Sat, 11 Oct 2003 03:43:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EOz-0007en-7t; Sat, 11 Oct 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EOa-0007dM-V4 for simple@optimus.ietf.org; Sat, 11 Oct 2003 03:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24886 for ; Sat, 11 Oct 2003 03:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EOY-0001eu-00 for simple@ietf.org; Sat, 11 Oct 2003 03:42:34 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A8EOX-0001eg-00 for simple@ietf.org; Sat, 11 Oct 2003 03:42:33 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9B7fwO8018450; Sat, 11 Oct 2003 02:41:58 -0500 (CDT) Received: from ericsson.com (fijowa02m28.sw.ericsson.se [136.225.183.92]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCLR8F; Sat, 11 Oct 2003 02:41:22 -0500 Message-ID: <3F87B441.5050604@ericsson.com> X-Sybari-Trust: 446b27e0 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <2038BCC78B1AD641891A0D1AE133DBB701797217@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797217@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Oct 2003 10:41:53 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am pretty sure that the final solution would be based on the work on the configuration/policies that is taking place in SIPPING. /Miguel hisham.khartabil@nokia.com wrote: > How about UA configuration from SIPPING (or any other configuration protocol)? > > /Hisham > > >>-----Original Message----- >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: Thursday, October 09, 2003 2:03 AM >>To: Adam Roach >>Cc: Jonathan Rosenberg; simple@ietf.org >>Subject: Re: [Simple] Discovery of an MSRP relay >> >> >>Adam: >> >>Your proposal works if I am in my home network. But if I am >>roaming, the >>DHCP server will be located in the roaming network, and will be >>provisioned with information about the MSRP relay in the roaming >>network. If this is the case, fine, it will work, but if by policy, I >>have to use the MSRP provided in my home network, and I am >>roaming, it >>won't work. Further more, if the roaming network does not >>offer an MSRP >>relay service, but my home network does, I won't be able to >>discover the >>MSRP relay server. >> >>I am not sure, at this stage, which of the above cases would >>be the case >>for MSRP relays... I just want to be prepared with solutions >>that solve >>any of the possible requirements. >> >>/Miguel >> >>Adam Roach wrote: >> >> >>>Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: >>> >>> >>> >>>>In another case, an MSRP relay is provided in a home network, >>>>and that MSRP relay is used no matter whether the user is >>>>attached directly to such network or indirectly through other >>>>networks. In this case DHCP won't obviously solve the problem. >>> >>> >>>For this case, I suggest we borrow a page from the well-understood, >>>time-tested, universally deployed, and demonstrably workable >>>mechanism that HTTP clients use to solve the problem of finding >>>HTTP proxies. >>> >>>/a >> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Oct 11 03:50:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25112; Sat, 11 Oct 2003 03:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EWl-0001je-00; Sat, 11 Oct 2003 03:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8EWl-0001jb-00; Sat, 11 Oct 2003 03:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EWj-000889-Ko; Sat, 11 Oct 2003 03:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EWK-00087f-UE for simple@optimus.ietf.org; Sat, 11 Oct 2003 03:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25106 for ; Sat, 11 Oct 2003 03:50:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EWI-0001jW-00 for simple@ietf.org; Sat, 11 Oct 2003 03:50:34 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A8EWH-0001jG-00 for simple@ietf.org; Sat, 11 Oct 2003 03:50:33 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9B7nwO8019046; Sat, 11 Oct 2003 02:49:58 -0500 (CDT) Received: from ericsson.com (fijowa02m28.sw.ericsson.se [136.225.183.92]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCLSKX; Sat, 11 Oct 2003 02:49:22 -0500 Message-ID: <3F87B622.3020708@ericsson.com> X-Sybari-Trust: 4de1d9aa 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <9BF66EBF6BEFD942915B4D4D45C051F3E864EC@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E864EC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Oct 2003 10:49:54 +0300 Content-Transfer-Encoding: 7bit Adam: As an example of today's behavior. Most of us in Europe using GPRS are provided with a private IPv4 address when we use the service. Additionally, every home network will provide a firewall. So an MSRP relay might be needed for the purpose of NAT/firewall traversal. The current practice indicates that, even in the case a user is roaming to another network, the public IP address belongs to the home network operator address space. So I was thinking of how to make the MSRP relay, perhaps provided in a home network, available to the UA. You suggested that the UA should be provisioned with such address. And obviously this solution works, but I would like to explore some automatic configuration mechanism, as experience reveals that users don't know how / don't bother to configure applications. As pointed out, the work done in SIPPING to configure or provide policies to the UA may solve the problem. /Miguel Adam Roach wrote: > Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > > >>...but if by policy, I >>have to use the MSRP provided in my home network, and I am >>roaming, it >>won't work. > > > I don't see why not. Your home MSRP relay would be provisioned > in your terminal, so it would know to go there. > > As an aside: what are you trying to do? The purpose of MSRP > relays is to solve issues with firewalls and/or NATs. Why would > you be tromboning back to your home network to find an MSRP > relay? I mean, if you can get to your home network, it's a > pretty good bet that you can hit the Internet as well, which > should give you a clear shot to the other participant (or > at least his relay). > > /a -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Oct 11 03:51:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25133 for ; Sat, 11 Oct 2003 03:51:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EWp-00089w-AQ for simple-archive@odin.ietf.org; Sat, 11 Oct 2003 03:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B7p7sf031365 for simple-archive@odin.ietf.org; Sat, 11 Oct 2003 03:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EWo-00089o-Ts for simple-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 03:51:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25112; Sat, 11 Oct 2003 03:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EWl-0001je-00; Sat, 11 Oct 2003 03:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8EWl-0001jb-00; Sat, 11 Oct 2003 03:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EWj-000889-Ko; Sat, 11 Oct 2003 03:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8EWK-00087f-UE for simple@optimus.ietf.org; Sat, 11 Oct 2003 03:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25106 for ; Sat, 11 Oct 2003 03:50:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8EWI-0001jW-00 for simple@ietf.org; Sat, 11 Oct 2003 03:50:34 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1A8EWH-0001jG-00 for simple@ietf.org; Sat, 11 Oct 2003 03:50:33 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9B7nwO8019046; Sat, 11 Oct 2003 02:49:58 -0500 (CDT) Received: from ericsson.com (fijowa02m28.sw.ericsson.se [136.225.183.92]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VCLSKX; Sat, 11 Oct 2003 02:49:22 -0500 Message-ID: <3F87B622.3020708@ericsson.com> X-Sybari-Trust: 4de1d9aa 406a040f c001c63b 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Discovery of an MSRP relay References: <9BF66EBF6BEFD942915B4D4D45C051F3E864EC@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E864EC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Oct 2003 10:49:54 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam: As an example of today's behavior. Most of us in Europe using GPRS are provided with a private IPv4 address when we use the service. Additionally, every home network will provide a firewall. So an MSRP relay might be needed for the purpose of NAT/firewall traversal. The current practice indicates that, even in the case a user is roaming to another network, the public IP address belongs to the home network operator address space. So I was thinking of how to make the MSRP relay, perhaps provided in a home network, available to the UA. You suggested that the UA should be provisioned with such address. And obviously this solution works, but I would like to explore some automatic configuration mechanism, as experience reveals that users don't know how / don't bother to configure applications. As pointed out, the work done in SIPPING to configure or provide policies to the UA may solve the problem. /Miguel Adam Roach wrote: > Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] writes: > > >>...but if by policy, I >>have to use the MSRP provided in my home network, and I am >>roaming, it >>won't work. > > > I don't see why not. Your home MSRP relay would be provisioned > in your terminal, so it would know to go there. > > As an aside: what are you trying to do? The purpose of MSRP > relays is to solve issues with firewalls and/or NATs. Why would > you be tromboning back to your home network to find an MSRP > relay? I mean, if you can get to your home network, it's a > pretty good bet that you can hit the Internet as well, which > should give you a clear shot to the other participant (or > at least his relay). > > /a -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Oct 12 07:29:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15046; Sun, 12 Oct 2003 07:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ePQ-0006p0-00; Sun, 12 Oct 2003 07:29:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8ePQ-0006ov-00; Sun, 12 Oct 2003 07:29:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ePF-0008NY-3n; Sun, 12 Oct 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8eOe-0008NA-4h for simple@optimus.ietf.org; Sun, 12 Oct 2003 07:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15032 for ; Sun, 12 Oct 2003 07:28:15 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8eOd-0006og-00 for simple@ietf.org; Sun, 12 Oct 2003 07:28:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A8eOc-0006oN-00 for simple@ietf.org; Sun, 12 Oct 2003 07:28:23 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9CBSLZ01975 for ; Sun, 12 Oct 2003 14:28:21 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 12 Oct 2003 14:28:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 12 Oct 2003 14:28:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcOPb8kPIPy40ji7SNuS9jUXQ1dXQwBQ2slg To: , Cc: , X-OriginalArrivalTime: 12 Oct 2003 11:28:13.0615 (UTC) FILETIME=[EC65DBF0:01C390B3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 12 Oct 2003 14:28:12 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, October 10, 2003 11:47 PM > To: Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > Paul Kyzivat wrote: >=20 > >=20 > >=20 > > Ben Campbell wrote: > >=20 > >> > >> That is not far from the same thing, since if there was a=20 > single idle=20 > >> session, it will take up to 1 timeout for each endpoint to send a=20 > >> request that the relay could respond to. > >> > >> But my point was, for Paul's scenario, it is not=20 > neccessary to wait=20 > >> for idle endpoints to get around to sending a request. You=20 > just have=20 > >> to wait long enough so that it is very unlikely that any=20 > transactions=20 > >> are still in play. A small number of minutes should be=20 > plenty of time. > >=20 > >=20 > > Hmm. How does waiting decrease the likelihood that messages=20 > are still in=20 > > play? Even though there have been no messages in the last N=20 > minutes, one=20 > > could just have been sent. > >=20 > > To be sure there are none, I think you must in general wait for the=20 > > timeout interval if the stream is idle. But if the stream=20 > is active, you=20 > > can just start sending the magic error code to every=20 > received message=20 > > for awhile, with the understanding that a sending, upon=20 > receiving this=20 > > code, will no longer send messages on the stream. Then,=20 > after enough=20 > > time has passed for all messages in the pipeline to have=20 > been received,=20 > > then stream can be shutdown. >=20 > If the goal is to make the relay notifies all endpoints prior to=20 > shutting down, then yes, you would have to wait for a full inactivity=20 > timeout period. But that was not the scenario you subscribed. If the=20 > relay begins sending 500 responses to any message at time T,=20 > then it can=20 > assume that there are no more outstanding transactions at=20 > T+N. Where N=20 > is the _transaction_ timout, rather than the inactivity=20 > timeout. (Now,=20 > we do not actually define the transaction timeout--it is currently=20 > listed as some "reasonable period of time." Maybe we need to specify=20 > that, but I am not sure this particular reason is enough to=20 > force that=20 > issue.) >=20 > So, at time T+N, the relay can reasonably assume that any transaction=20 > that was already in progress when it started sending the 500s=20 > has either=20 > completed or timed out. I suppose there could be requests=20 > that are still=20 > sitting in the endpoints TCP send buffer and never get a 500,=20 > but that=20 > would be a pretty small percentages of messages overall. >=20 > >=20 > > To speed up shutdown of an inactive stream I think either=20 > the inactivity=20 > > timeout needs to be reduced, or else there needs to be a special=20 > > graceful close message that can be sent. >=20 > I gather that you are looking for a "perfectly" graceful=20 > shutdown, that=20 > guarantees that the endpoint will know for sure that a given=20 > message has=20 > been delivered or not delivered. I accept that it may be polite=20 > behavior to minimize messages in "limbo". But nothing in MSRP=20 > guarantees=20 > that a SEND transaction that times out without a response has not=20 > actually been delivered. We can only guarantee that, if you get a=20 > successful response back, the message _has_ been delivered. >=20 > So I think it is reasonable to suggest that a relay wait a couple of=20 > minutes after it stops relaying requests before it actually=20 > shuts down.=20 > I don't think it is reasonable to ask it to wait 12 minutes,=20 > and I don't=20 > think that this particular issue provides sufficient motivation to=20 > reduce the idle timer. >=20 > What do others think on this point? If you don't wait the full idle timeout period, then I don't see the = point in waiting a couple of mins before shutting down. It is better to = just shut down immediately then. As I said earlier, relay shuts down after the full timeout period, or = until it know it has sent 4xx (or 5xx) responses to SEND requests sent = by all the participants in all session. Whichever is reached first. In = this way, you guarantee that either the clients have been notified of = such shutdown on that the clients have timed out themselves anyway. /Hisham >=20 > >=20 > > Paul >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Oct 12 07:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15081 for ; Sun, 12 Oct 2003 07:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ePR-0008Od-Ql for simple-archive@odin.ietf.org; Sun, 12 Oct 2003 07:29:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9CBTDPs032272 for simple-archive@odin.ietf.org; Sun, 12 Oct 2003 07:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ePR-0008OR-LB for simple-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 07:29:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15046; Sun, 12 Oct 2003 07:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ePQ-0006p0-00; Sun, 12 Oct 2003 07:29:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8ePQ-0006ov-00; Sun, 12 Oct 2003 07:29:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ePF-0008NY-3n; Sun, 12 Oct 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8eOe-0008NA-4h for simple@optimus.ietf.org; Sun, 12 Oct 2003 07:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15032 for ; Sun, 12 Oct 2003 07:28:15 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8eOd-0006og-00 for simple@ietf.org; Sun, 12 Oct 2003 07:28:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A8eOc-0006oN-00 for simple@ietf.org; Sun, 12 Oct 2003 07:28:23 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9CBSLZ01975 for ; Sun, 12 Oct 2003 14:28:21 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 12 Oct 2003 14:28:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 12 Oct 2003 14:28:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcOPb8kPIPy40ji7SNuS9jUXQ1dXQwBQ2slg To: , Cc: , X-OriginalArrivalTime: 12 Oct 2003 11:28:13.0615 (UTC) FILETIME=[EC65DBF0:01C390B3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 12 Oct 2003 14:28:12 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, October 10, 2003 11:47 PM > To: Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 > Paul Kyzivat wrote: >=20 > >=20 > >=20 > > Ben Campbell wrote: > >=20 > >> > >> That is not far from the same thing, since if there was a=20 > single idle=20 > >> session, it will take up to 1 timeout for each endpoint to send a=20 > >> request that the relay could respond to. > >> > >> But my point was, for Paul's scenario, it is not=20 > neccessary to wait=20 > >> for idle endpoints to get around to sending a request. You=20 > just have=20 > >> to wait long enough so that it is very unlikely that any=20 > transactions=20 > >> are still in play. A small number of minutes should be=20 > plenty of time. > >=20 > >=20 > > Hmm. How does waiting decrease the likelihood that messages=20 > are still in=20 > > play? Even though there have been no messages in the last N=20 > minutes, one=20 > > could just have been sent. > >=20 > > To be sure there are none, I think you must in general wait for the=20 > > timeout interval if the stream is idle. But if the stream=20 > is active, you=20 > > can just start sending the magic error code to every=20 > received message=20 > > for awhile, with the understanding that a sending, upon=20 > receiving this=20 > > code, will no longer send messages on the stream. Then,=20 > after enough=20 > > time has passed for all messages in the pipeline to have=20 > been received,=20 > > then stream can be shutdown. >=20 > If the goal is to make the relay notifies all endpoints prior to=20 > shutting down, then yes, you would have to wait for a full inactivity=20 > timeout period. But that was not the scenario you subscribed. If the=20 > relay begins sending 500 responses to any message at time T,=20 > then it can=20 > assume that there are no more outstanding transactions at=20 > T+N. Where N=20 > is the _transaction_ timout, rather than the inactivity=20 > timeout. (Now,=20 > we do not actually define the transaction timeout--it is currently=20 > listed as some "reasonable period of time." Maybe we need to specify=20 > that, but I am not sure this particular reason is enough to=20 > force that=20 > issue.) >=20 > So, at time T+N, the relay can reasonably assume that any transaction=20 > that was already in progress when it started sending the 500s=20 > has either=20 > completed or timed out. I suppose there could be requests=20 > that are still=20 > sitting in the endpoints TCP send buffer and never get a 500,=20 > but that=20 > would be a pretty small percentages of messages overall. >=20 > >=20 > > To speed up shutdown of an inactive stream I think either=20 > the inactivity=20 > > timeout needs to be reduced, or else there needs to be a special=20 > > graceful close message that can be sent. >=20 > I gather that you are looking for a "perfectly" graceful=20 > shutdown, that=20 > guarantees that the endpoint will know for sure that a given=20 > message has=20 > been delivered or not delivered. I accept that it may be polite=20 > behavior to minimize messages in "limbo". But nothing in MSRP=20 > guarantees=20 > that a SEND transaction that times out without a response has not=20 > actually been delivered. We can only guarantee that, if you get a=20 > successful response back, the message _has_ been delivered. >=20 > So I think it is reasonable to suggest that a relay wait a couple of=20 > minutes after it stops relaying requests before it actually=20 > shuts down.=20 > I don't think it is reasonable to ask it to wait 12 minutes,=20 > and I don't=20 > think that this particular issue provides sufficient motivation to=20 > reduce the idle timer. >=20 > What do others think on this point? If you don't wait the full idle timeout period, then I don't see the = point in waiting a couple of mins before shutting down. It is better to = just shut down immediately then. As I said earlier, relay shuts down after the full timeout period, or = until it know it has sent 4xx (or 5xx) responses to SEND requests sent = by all the participants in all session. Whichever is reached first. In = this way, you guarantee that either the clients have been notified of = such shutdown on that the clients have timed out themselves anyway. /Hisham >=20 > >=20 > > Paul >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Oct 12 07:54:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15715; Sun, 12 Oct 2003 07:54:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8enY-00072j-00; Sun, 12 Oct 2003 07:54:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8enX-00072g-00; Sun, 12 Oct 2003 07:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8enR-00016Q-7R; Sun, 12 Oct 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8en9-00014w-LB for simple@optimus.ietf.org; Sun, 12 Oct 2003 07:53:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15712 for ; Sun, 12 Oct 2003 07:53:35 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8en8-00072b-00 for simple@ietf.org; Sun, 12 Oct 2003 07:53:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A8en8-00072Y-00 for simple@ietf.org; Sun, 12 Oct 2003 07:53:42 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9CBreZ15662 for ; Sun, 12 Oct 2003 14:53:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 12 Oct 2003 14:53:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 12 Oct 2003 14:53:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Overload (was MSRP: Administrative shutdown of relays) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179723C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Overload (was MSRP: Administrative shutdown of relays) Thread-Index: AcOPPXDEhzc4SivjTR+CG+vS/Hyv3QBd9RIg To: , X-OriginalArrivalTime: 12 Oct 2003 11:53:40.0651 (UTC) FILETIME=[7A950FB0:01C390B7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 12 Oct 2003 14:53:40 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, October 10, 2003 5:46 PM > To: simple@ietf.org > Subject: [Simple] Overload (was MSRP: Administrative shutdown=20 > of relays) >=20 >=20 > (as not-the-chair): >=20 > It occurs to me that we have another scenario that deserves=20 > exploration. > What do we have a relay do when it reaches capacity? >=20 > Rejecting new binds is obvious, but what do we do when traffic on > existing sessions begins to overwhelm the relay?=20 Maybe the relay shouldn't have accepted that number of sessions in the = first place. Network administrators should know the capacity of their = relays and load balance sessions accordingly. If existing session = capacity overwhelms a relay, you can blame it on the administrator for = the relay crashing :) Alternatively, I think you suggestion below works (with a minor = adjustment) > Beginning to=20 > terminate > some of them by 481ing selected SENDs would help, but that=20 > would likely > result in an immediate reattempt to BIND (along with a TCP connect). The relay can then reject those BINDs. /Hisham > Do we want to avoid that and have some way to say "Go away and don't > bother me again until x amount of time has passed"? >=20 > RjS >=20 > On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > > I had originally read Hisham's suggestion as having the=20 > relay wait for=20 > > up to a full inactivity timeout between the time it stops=20 > allowing SEND=20 > > and the time it drops the connections. Assuming this timer=20 > value is 10=20 > > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > >=20 > > But in the case you mention, a full timeout would not be=20 > needed. Rather,=20 > > just waiting a reasonable time to make sure that there are no SEND=20 > > transactions in play would be sufficient. Is that what you=20 > had in mind?=20 > > If so, I don't have a problem putting in as a SHOULD strength. > >=20 > > Does anyone have thoughts on an appropriate response code=20 > for this? We=20 > > already have 481 for no session, which seems borderline=20 > appropriate. We=20 > > also have 500 which means "unable to forward SEND request" which is=20 > > exactly the case but could be a little too generic. Is there a case=20 > > where a client would handle a 500 different than some 5xx "relay=20 > > shutting down" response? > >=20 > >=20 > >=20 > >=20 > >=20 > > Paul Kyzivat wrote: > >=20 > > > What Hisham says sounds good to me. > > >=20 > > > I'm trying to think of a scenario where this makes a=20 > difference. I think=20 > > > I have one: > > >=20 > > > Suppose there is an MSRP session between A and B, and=20 > involving a relay=20 > > > R1. Some administrator wants to shut down R1. This=20 > doesn't mean that A=20 > > > and B want to stop chatting. When the relay goes down, the chat=20 > > > applications will probably want to attempt renegotiation=20 > of the session,=20 > > > via a reINVITE. > > >=20 > > > Assuming they can find a substitute relay, this should=20 > work ok. But=20 > > > there is of course the question of messages already sent:=20 > have they been=20 > > > delivered, or should they be sent again? If they are sent=20 > again, the=20 > > > recipient may see the same message appear twice. > > >=20 > > > If the connection is just torn down (option 2) then A and=20 > B have no way=20 > > > of knowing whether the message outstanding were received,=20 > and so will=20 > > > have to assume no and retransmit. If option 1 is used, then the=20 > > > connection will go down smoothly and there will be no=20 > question, so no=20 > > > repeated messages. > > >=20 > > > Paul > > >=20 > > > hisham.khartabil@nokia.com wrote: > > >=20 > > >> Does a 400 response for a SEND request terminate the=20 > MSRP session? If=20 > > >> so, then option 1 (or a variant thereof) would be simple=20 > enough: A=20 > > >> Relay refuses all SEND requests, once it has done so for every=20 > > >> connection, it can assume all sessions are done and shut down. > > >> > > >> Of course option 2 is much SIMPLEr. > > >> > > >> /Hisham > > >> > > >> > > >>> -----Original Message----- > > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > > >>> Sent: Thursday, October 09, 2003 4:26 PM > > >>> To: Khartabil Hisham (NMP-MSW/Helsinki);=20 > bcampbell@dynamicsoft.com; > > >>> simple@ietf.org > > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > >>> > > >>> > > >>> The only benefit I can see from using option 1 would be that an > > >>> appropriate response/reason phrase to the SEND requests=20 > would allow a > > >>> more graceful shutdown of sessions in an endpoint (The=20 > host of this > > >>> session is terminating so I must dispose of the MSRP=20 > session) BUT I also > > >>> see that option 2 keeps it SIMPLE ;-). > > >>> > > >>> Chris. > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > >>>> Sent: 09 October 2003 14:13 > > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > >>>> > > >>>> I vote for option 2. > > >>>> > > >>>> /Hisham > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > > >>>>> To: simple@ietf.org > > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > > >>>>> > > >>>>> > > >>>>> I just realized that we had one more subject brought up in > > >>>>> Vienna where > > >>>>> we decided to "take it to the list". Which of course has not > > >>>>> yet happened. > > >>>>> > > >>>>> The question was brought up that, in the previous version of > > >>>>> MSRP where > > >>>>> we refreshed state with BIND and VISIT, we had an implied > > >>>>> mechanism by > > >>>>> which a relay could shed load for shutdown. That is, is > > >>>>> starts refusing > > >>>>> refreshes until all sessions have expired. > > >>>>> > > >>>>> Since we have moved to a keep-alive approach rather than=20 > > >>>> > > >>>> > > >>> the refresh > > >>> > > >>>>> approach, this is not as clean. A couple of approaches=20 > > >>>> > > >>>> > > >>> come to mind: > > >>> > > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > > >>>>> sessions are > > >>>>> gone when the timeout period expires. > > >>>>> > > >>>>> 2) Just close all TCP connections and let the endpoints=20 > > >>>> > > >>>> > > >>> deal with it. > > >>> > > >>>>> I find myself leaning toward 2, as 1 does not allow the > > >>>>> endpoints to do > > >>>>> anything useful on the session anyway. > > >>>>> > > >>>>> Thoughts? > > >>>>> > > >>>>> Ben. > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Simple mailing list > > >>>>> Simple@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/simple > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Simple mailing list > > >>>> Simple@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/simple > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> Simple mailing list > > >> Simple@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/simple > > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Oct 12 07:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15742 for ; Sun, 12 Oct 2003 07:54:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8enZ-0001AK-H3 for simple-archive@odin.ietf.org; Sun, 12 Oct 2003 07:54:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9CBs9D3004474 for simple-archive@odin.ietf.org; Sun, 12 Oct 2003 07:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8enZ-000195-8q for simple-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 07:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15715; Sun, 12 Oct 2003 07:54:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8enY-00072j-00; Sun, 12 Oct 2003 07:54:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8enX-00072g-00; Sun, 12 Oct 2003 07:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8enR-00016Q-7R; Sun, 12 Oct 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8en9-00014w-LB for simple@optimus.ietf.org; Sun, 12 Oct 2003 07:53:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15712 for ; Sun, 12 Oct 2003 07:53:35 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8en8-00072b-00 for simple@ietf.org; Sun, 12 Oct 2003 07:53:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A8en8-00072Y-00 for simple@ietf.org; Sun, 12 Oct 2003 07:53:42 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9CBreZ15662 for ; Sun, 12 Oct 2003 14:53:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 12 Oct 2003 14:53:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 12 Oct 2003 14:53:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Overload (was MSRP: Administrative shutdown of relays) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179723C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Overload (was MSRP: Administrative shutdown of relays) Thread-Index: AcOPPXDEhzc4SivjTR+CG+vS/Hyv3QBd9RIg To: , X-OriginalArrivalTime: 12 Oct 2003 11:53:40.0651 (UTC) FILETIME=[7A950FB0:01C390B7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 12 Oct 2003 14:53:40 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, October 10, 2003 5:46 PM > To: simple@ietf.org > Subject: [Simple] Overload (was MSRP: Administrative shutdown=20 > of relays) >=20 >=20 > (as not-the-chair): >=20 > It occurs to me that we have another scenario that deserves=20 > exploration. > What do we have a relay do when it reaches capacity? >=20 > Rejecting new binds is obvious, but what do we do when traffic on > existing sessions begins to overwhelm the relay?=20 Maybe the relay shouldn't have accepted that number of sessions in the = first place. Network administrators should know the capacity of their = relays and load balance sessions accordingly. If existing session = capacity overwhelms a relay, you can blame it on the administrator for = the relay crashing :) Alternatively, I think you suggestion below works (with a minor = adjustment) > Beginning to=20 > terminate > some of them by 481ing selected SENDs would help, but that=20 > would likely > result in an immediate reattempt to BIND (along with a TCP connect). The relay can then reject those BINDs. /Hisham > Do we want to avoid that and have some way to say "Go away and don't > bother me again until x amount of time has passed"? >=20 > RjS >=20 > On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > > I had originally read Hisham's suggestion as having the=20 > relay wait for=20 > > up to a full inactivity timeout between the time it stops=20 > allowing SEND=20 > > and the time it drops the connections. Assuming this timer=20 > value is 10=20 > > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > >=20 > > But in the case you mention, a full timeout would not be=20 > needed. Rather,=20 > > just waiting a reasonable time to make sure that there are no SEND=20 > > transactions in play would be sufficient. Is that what you=20 > had in mind?=20 > > If so, I don't have a problem putting in as a SHOULD strength. > >=20 > > Does anyone have thoughts on an appropriate response code=20 > for this? We=20 > > already have 481 for no session, which seems borderline=20 > appropriate. We=20 > > also have 500 which means "unable to forward SEND request" which is=20 > > exactly the case but could be a little too generic. Is there a case=20 > > where a client would handle a 500 different than some 5xx "relay=20 > > shutting down" response? > >=20 > >=20 > >=20 > >=20 > >=20 > > Paul Kyzivat wrote: > >=20 > > > What Hisham says sounds good to me. > > >=20 > > > I'm trying to think of a scenario where this makes a=20 > difference. I think=20 > > > I have one: > > >=20 > > > Suppose there is an MSRP session between A and B, and=20 > involving a relay=20 > > > R1. Some administrator wants to shut down R1. This=20 > doesn't mean that A=20 > > > and B want to stop chatting. When the relay goes down, the chat=20 > > > applications will probably want to attempt renegotiation=20 > of the session,=20 > > > via a reINVITE. > > >=20 > > > Assuming they can find a substitute relay, this should=20 > work ok. But=20 > > > there is of course the question of messages already sent:=20 > have they been=20 > > > delivered, or should they be sent again? If they are sent=20 > again, the=20 > > > recipient may see the same message appear twice. > > >=20 > > > If the connection is just torn down (option 2) then A and=20 > B have no way=20 > > > of knowing whether the message outstanding were received,=20 > and so will=20 > > > have to assume no and retransmit. If option 1 is used, then the=20 > > > connection will go down smoothly and there will be no=20 > question, so no=20 > > > repeated messages. > > >=20 > > > Paul > > >=20 > > > hisham.khartabil@nokia.com wrote: > > >=20 > > >> Does a 400 response for a SEND request terminate the=20 > MSRP session? If=20 > > >> so, then option 1 (or a variant thereof) would be simple=20 > enough: A=20 > > >> Relay refuses all SEND requests, once it has done so for every=20 > > >> connection, it can assume all sessions are done and shut down. > > >> > > >> Of course option 2 is much SIMPLEr. > > >> > > >> /Hisham > > >> > > >> > > >>> -----Original Message----- > > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > > >>> Sent: Thursday, October 09, 2003 4:26 PM > > >>> To: Khartabil Hisham (NMP-MSW/Helsinki);=20 > bcampbell@dynamicsoft.com; > > >>> simple@ietf.org > > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > >>> > > >>> > > >>> The only benefit I can see from using option 1 would be that an > > >>> appropriate response/reason phrase to the SEND requests=20 > would allow a > > >>> more graceful shutdown of sessions in an endpoint (The=20 > host of this > > >>> session is terminating so I must dispose of the MSRP=20 > session) BUT I also > > >>> see that option 2 keeps it SIMPLE ;-). > > >>> > > >>> Chris. > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > >>>> Sent: 09 October 2003 14:13 > > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > >>>> > > >>>> I vote for option 2. > > >>>> > > >>>> /Hisham > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > > >>>>> To: simple@ietf.org > > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > > >>>>> > > >>>>> > > >>>>> I just realized that we had one more subject brought up in > > >>>>> Vienna where > > >>>>> we decided to "take it to the list". Which of course has not > > >>>>> yet happened. > > >>>>> > > >>>>> The question was brought up that, in the previous version of > > >>>>> MSRP where > > >>>>> we refreshed state with BIND and VISIT, we had an implied > > >>>>> mechanism by > > >>>>> which a relay could shed load for shutdown. That is, is > > >>>>> starts refusing > > >>>>> refreshes until all sessions have expired. > > >>>>> > > >>>>> Since we have moved to a keep-alive approach rather than=20 > > >>>> > > >>>> > > >>> the refresh > > >>> > > >>>>> approach, this is not as clean. A couple of approaches=20 > > >>>> > > >>>> > > >>> come to mind: > > >>> > > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > > >>>>> sessions are > > >>>>> gone when the timeout period expires. > > >>>>> > > >>>>> 2) Just close all TCP connections and let the endpoints=20 > > >>>> > > >>>> > > >>> deal with it. > > >>> > > >>>>> I find myself leaning toward 2, as 1 does not allow the > > >>>>> endpoints to do > > >>>>> anything useful on the session anyway. > > >>>>> > > >>>>> Thoughts? > > >>>>> > > >>>>> Ben. > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Simple mailing list > > >>>>> Simple@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/simple > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Simple mailing list > > >>>> Simple@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/simple > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> Simple mailing list > > >> Simple@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/simple > > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 09:18:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03119; Mon, 13 Oct 2003 09:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92aV-0002JU-00; Mon, 13 Oct 2003 09:18:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A92aU-0002JP-00; Mon, 13 Oct 2003 09:18:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92aH-0000JL-4E; Mon, 13 Oct 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92ZN-0000II-Gh for simple@optimus.ietf.org; Mon, 13 Oct 2003 09:17:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03073 for ; Mon, 13 Oct 2003 09:16:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92ZL-0002Ij-00 for simple@ietf.org; Mon, 13 Oct 2003 09:17:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A92ZL-0002IB-00 for simple@ietf.org; Mon, 13 Oct 2003 09:17:03 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DDGTAW018385; Mon, 13 Oct 2003 09:16:30 -0400 (EDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC04372; Mon, 13 Oct 2003 09:16:28 -0400 (EDT) Message-ID: <3F8AA5AB.4010804@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 09:16:27 -0400 Content-Transfer-Encoding: 7bit hisham - I agree. Paul hisham.khartabil@nokia.com wrote: > > If you don't wait the full idle timeout period, > then I don't see the point in waiting a couple of mins > before shutting down. It is better to just shut down > immediately then. > > As I said earlier, relay shuts down after the full timeout > period, or until it know it has sent 4xx (or 5xx) responses > to SEND requests sent by all the participants in all session. > Whichever is reached first. In this way, you guarantee that > either the clients have been notified of such shutdown on > that the clients have timed out themselves anyway. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 09:18:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03149 for ; Mon, 13 Oct 2003 09:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92aX-0000KU-OP for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 09:18:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DDIHVA001260 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 09:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92aX-0000KF-JZ for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 09:18:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03119; Mon, 13 Oct 2003 09:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92aV-0002JU-00; Mon, 13 Oct 2003 09:18:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A92aU-0002JP-00; Mon, 13 Oct 2003 09:18:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92aH-0000JL-4E; Mon, 13 Oct 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92ZN-0000II-Gh for simple@optimus.ietf.org; Mon, 13 Oct 2003 09:17:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03073 for ; Mon, 13 Oct 2003 09:16:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92ZL-0002Ij-00 for simple@ietf.org; Mon, 13 Oct 2003 09:17:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A92ZL-0002IB-00 for simple@ietf.org; Mon, 13 Oct 2003 09:17:03 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DDGTAW018385; Mon, 13 Oct 2003 09:16:30 -0400 (EDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC04372; Mon, 13 Oct 2003 09:16:28 -0400 (EDT) Message-ID: <3F8AA5AB.4010804@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 09:16:27 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham - I agree. Paul hisham.khartabil@nokia.com wrote: > > If you don't wait the full idle timeout period, > then I don't see the point in waiting a couple of mins > before shutting down. It is better to just shut down > immediately then. > > As I said earlier, relay shuts down after the full timeout > period, or until it know it has sent 4xx (or 5xx) responses > to SEND requests sent by all the participants in all session. > Whichever is reached first. In this way, you guarantee that > either the clients have been notified of such shutdown on > that the clients have timed out themselves anyway. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 09:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04739; Mon, 13 Oct 2003 09:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A932K-0001qN-Oo; Mon, 13 Oct 2003 09:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A931g-0001jw-UJ for simple@optimus.ietf.org; Mon, 13 Oct 2003 09:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04699 for ; Mon, 13 Oct 2003 09:46:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A931f-0002lD-00 for simple@ietf.org; Mon, 13 Oct 2003 09:46:19 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A931e-0002ku-00 for simple@ietf.org; Mon, 13 Oct 2003 09:46:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9DDjdd30083; Mon, 13 Oct 2003 08:45:39 -0500 Subject: RE: [Simple] Overload (was MSRP: Administrative shutdown of relays) From: Robert Sparks To: Hisham Khartabil Cc: simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179723C@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179723C@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1066052738.946.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 08:45:38 -0500 Content-Transfer-Encoding: 7bit On Sun, 2003-10-12 at 06:53, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Friday, October 10, 2003 5:46 PM > > To: simple@ietf.org > > Subject: [Simple] Overload (was MSRP: Administrative shutdown > > of relays) > > > > > > (as not-the-chair): > > > > It occurs to me that we have another scenario that deserves > > exploration. > > What do we have a relay do when it reaches capacity? > > > > Rejecting new binds is obvious, but what do we do when traffic on > > existing sessions begins to overwhelm the relay? > > Maybe the relay shouldn't have accepted that number of sessions in the first place. Network administrators should know the capacity of their relays and load balance sessions accordingly. If existing session capacity overwhelms a relay, you can blame it on the administrator for the relay crashing :) I could buy that if the load introduced by a given session were predictable, but that's not the general case. You could be well below any engineered limit of sessions and have one or two begin consuming all of a relays resources (without intending to be abusive). > > Alternatively, I think you suggestion below works (with a minor adjustment) > > > Beginning to > > terminate > > some of them by 481ing selected SENDs would help, but that > > would likely > > result in an immediate reattempt to BIND (along with a TCP connect). > > The relay can then reject those BINDs. I suggest we want be able to avoid the load of accepting this TCP connection and processing a BIND request just to reject it. > > /Hisham > > > > Do we want to avoid that and have some way to say "Go away and don't > > bother me again until x amount of time has passed"? > > > > RjS > > > > On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > > > I had originally read Hisham's suggestion as having the > > relay wait for > > > up to a full inactivity timeout between the time it stops > > allowing SEND > > > and the time it drops the connections. Assuming this timer > > value is 10 > > > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > > > > > > But in the case you mention, a full timeout would not be > > needed. Rather, > > > just waiting a reasonable time to make sure that there are no SEND > > > transactions in play would be sufficient. Is that what you > > had in mind? > > > If so, I don't have a problem putting in as a SHOULD strength. > > > > > > Does anyone have thoughts on an appropriate response code > > for this? We > > > already have 481 for no session, which seems borderline > > appropriate. We > > > also have 500 which means "unable to forward SEND request" which is > > > exactly the case but could be a little too generic. Is there a case > > > where a client would handle a 500 different than some 5xx "relay > > > shutting down" response? > > > > > > > > > > > > > > > > > > Paul Kyzivat wrote: > > > > > > > What Hisham says sounds good to me. > > > > > > > > I'm trying to think of a scenario where this makes a > > difference. I think > > > > I have one: > > > > > > > > Suppose there is an MSRP session between A and B, and > > involving a relay > > > > R1. Some administrator wants to shut down R1. This > > doesn't mean that A > > > > and B want to stop chatting. When the relay goes down, the chat > > > > applications will probably want to attempt renegotiation > > of the session, > > > > via a reINVITE. > > > > > > > > Assuming they can find a substitute relay, this should > > work ok. But > > > > there is of course the question of messages already sent: > > have they been > > > > delivered, or should they be sent again? If they are sent > > again, the > > > > recipient may see the same message appear twice. > > > > > > > > If the connection is just torn down (option 2) then A and > > B have no way > > > > of knowing whether the message outstanding were received, > > and so will > > > > have to assume no and retransmit. If option 1 is used, then the > > > > connection will go down smoothly and there will be no > > question, so no > > > > repeated messages. > > > > > > > > Paul > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > > > > >> Does a 400 response for a SEND request terminate the > > MSRP session? If > > > >> so, then option 1 (or a variant thereof) would be simple > > enough: A > > > >> Relay refuses all SEND requests, once it has done so for every > > > >> connection, it can assume all sessions are done and shut down. > > > >> > > > >> Of course option 2 is much SIMPLEr. > > > >> > > > >> /Hisham > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > > > >>> Sent: Thursday, October 09, 2003 4:26 PM > > > >>> To: Khartabil Hisham (NMP-MSW/Helsinki); > > bcampbell@dynamicsoft.com; > > > >>> simple@ietf.org > > > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >>> > > > >>> > > > >>> The only benefit I can see from using option 1 would be that an > > > >>> appropriate response/reason phrase to the SEND requests > > would allow a > > > >>> more graceful shutdown of sessions in an endpoint (The > > host of this > > > >>> session is terminating so I must dispose of the MSRP > > session) BUT I also > > > >>> see that option 2 keeps it SIMPLE ;-). > > > >>> > > > >>> Chris. > > > >>> > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > >>>> Sent: 09 October 2003 14:13 > > > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > > > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >>>> > > > >>>> I vote for option 2. > > > >>>> > > > >>>> /Hisham > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > > > >>>>> To: simple@ietf.org > > > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > > > >>>>> > > > >>>>> > > > >>>>> I just realized that we had one more subject brought up in > > > >>>>> Vienna where > > > >>>>> we decided to "take it to the list". Which of course has not > > > >>>>> yet happened. > > > >>>>> > > > >>>>> The question was brought up that, in the previous version of > > > >>>>> MSRP where > > > >>>>> we refreshed state with BIND and VISIT, we had an implied > > > >>>>> mechanism by > > > >>>>> which a relay could shed load for shutdown. That is, is > > > >>>>> starts refusing > > > >>>>> refreshes until all sessions have expired. > > > >>>>> > > > >>>>> Since we have moved to a keep-alive approach rather than > > > >>>> > > > >>>> > > > >>> the refresh > > > >>> > > > >>>>> approach, this is not as clean. A couple of approaches > > > >>>> > > > >>>> > > > >>> come to mind: > > > >>> > > > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > > > >>>>> sessions are > > > >>>>> gone when the timeout period expires. > > > >>>>> > > > >>>>> 2) Just close all TCP connections and let the endpoints > > > >>>> > > > >>>> > > > >>> deal with it. > > > >>> > > > >>>>> I find myself leaning toward 2, as 1 does not allow the > > > >>>>> endpoints to do > > > >>>>> anything useful on the session anyway. > > > >>>>> > > > >>>>> Thoughts? > > > >>>>> > > > >>>>> Ben. > > > >>>>> > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> Simple mailing list > > > >>>>> Simple@ietf.org > > > >>>>> https://www1.ietf.org/mailman/listinfo/simple > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Simple mailing list > > > >>>> Simple@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/simple > > > >>> > > > >>> > > > >> > > > >> _______________________________________________ > > > >> Simple mailing list > > > >> Simple@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/simple > > > >> > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 09:48:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04803 for ; Mon, 13 Oct 2003 09:48:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9333-00025k-8q for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 09:47:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DDljDI008040 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 09:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9333-00025b-1H for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 09:47:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04739; Mon, 13 Oct 2003 09:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A932K-0001qN-Oo; Mon, 13 Oct 2003 09:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A931g-0001jw-UJ for simple@optimus.ietf.org; Mon, 13 Oct 2003 09:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04699 for ; Mon, 13 Oct 2003 09:46:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A931f-0002lD-00 for simple@ietf.org; Mon, 13 Oct 2003 09:46:19 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A931e-0002ku-00 for simple@ietf.org; Mon, 13 Oct 2003 09:46:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9DDjdd30083; Mon, 13 Oct 2003 08:45:39 -0500 Subject: RE: [Simple] Overload (was MSRP: Administrative shutdown of relays) From: Robert Sparks To: Hisham Khartabil Cc: simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179723C@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179723C@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1066052738.946.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 08:45:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sun, 2003-10-12 at 06:53, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Friday, October 10, 2003 5:46 PM > > To: simple@ietf.org > > Subject: [Simple] Overload (was MSRP: Administrative shutdown > > of relays) > > > > > > (as not-the-chair): > > > > It occurs to me that we have another scenario that deserves > > exploration. > > What do we have a relay do when it reaches capacity? > > > > Rejecting new binds is obvious, but what do we do when traffic on > > existing sessions begins to overwhelm the relay? > > Maybe the relay shouldn't have accepted that number of sessions in the first place. Network administrators should know the capacity of their relays and load balance sessions accordingly. If existing session capacity overwhelms a relay, you can blame it on the administrator for the relay crashing :) I could buy that if the load introduced by a given session were predictable, but that's not the general case. You could be well below any engineered limit of sessions and have one or two begin consuming all of a relays resources (without intending to be abusive). > > Alternatively, I think you suggestion below works (with a minor adjustment) > > > Beginning to > > terminate > > some of them by 481ing selected SENDs would help, but that > > would likely > > result in an immediate reattempt to BIND (along with a TCP connect). > > The relay can then reject those BINDs. I suggest we want be able to avoid the load of accepting this TCP connection and processing a BIND request just to reject it. > > /Hisham > > > > Do we want to avoid that and have some way to say "Go away and don't > > bother me again until x amount of time has passed"? > > > > RjS > > > > On Fri, 2003-10-10 at 09:35, Ben Campbell wrote: > > > I had originally read Hisham's suggestion as having the > > relay wait for > > > up to a full inactivity timeout between the time it stops > > allowing SEND > > > and the time it drops the connections. Assuming this timer > > value is 10 > > > (or 12 for Adam :-) ) minutes, this seemed like an excessive burden. > > > > > > But in the case you mention, a full timeout would not be > > needed. Rather, > > > just waiting a reasonable time to make sure that there are no SEND > > > transactions in play would be sufficient. Is that what you > > had in mind? > > > If so, I don't have a problem putting in as a SHOULD strength. > > > > > > Does anyone have thoughts on an appropriate response code > > for this? We > > > already have 481 for no session, which seems borderline > > appropriate. We > > > also have 500 which means "unable to forward SEND request" which is > > > exactly the case but could be a little too generic. Is there a case > > > where a client would handle a 500 different than some 5xx "relay > > > shutting down" response? > > > > > > > > > > > > > > > > > > Paul Kyzivat wrote: > > > > > > > What Hisham says sounds good to me. > > > > > > > > I'm trying to think of a scenario where this makes a > > difference. I think > > > > I have one: > > > > > > > > Suppose there is an MSRP session between A and B, and > > involving a relay > > > > R1. Some administrator wants to shut down R1. This > > doesn't mean that A > > > > and B want to stop chatting. When the relay goes down, the chat > > > > applications will probably want to attempt renegotiation > > of the session, > > > > via a reINVITE. > > > > > > > > Assuming they can find a substitute relay, this should > > work ok. But > > > > there is of course the question of messages already sent: > > have they been > > > > delivered, or should they be sent again? If they are sent > > again, the > > > > recipient may see the same message appear twice. > > > > > > > > If the connection is just torn down (option 2) then A and > > B have no way > > > > of knowing whether the message outstanding were received, > > and so will > > > > have to assume no and retransmit. If option 1 is used, then the > > > > connection will go down smoothly and there will be no > > question, so no > > > > repeated messages. > > > > > > > > Paul > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > > > > >> Does a 400 response for a SEND request terminate the > > MSRP session? If > > > >> so, then option 1 (or a variant thereof) would be simple > > enough: A > > > >> Relay refuses all SEND requests, once it has done so for every > > > >> connection, it can assume all sessions are done and shut down. > > > >> > > > >> Of course option 2 is much SIMPLEr. > > > >> > > > >> /Hisham > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > > > >>> Sent: Thursday, October 09, 2003 4:26 PM > > > >>> To: Khartabil Hisham (NMP-MSW/Helsinki); > > bcampbell@dynamicsoft.com; > > > >>> simple@ietf.org > > > >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >>> > > > >>> > > > >>> The only benefit I can see from using option 1 would be that an > > > >>> appropriate response/reason phrase to the SEND requests > > would allow a > > > >>> more graceful shutdown of sessions in an endpoint (The > > host of this > > > >>> session is terminating so I must dispose of the MSRP > > session) BUT I also > > > >>> see that option 2 keeps it SIMPLE ;-). > > > >>> > > > >>> Chris. > > > >>> > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > >>>> Sent: 09 October 2003 14:13 > > > >>>> To: bcampbell@dynamicsoft.com; simple@ietf.org > > > >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >>>> > > > >>>> I vote for option 2. > > > >>>> > > > >>>> /Hisham > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > >>>>> Sent: Wednesday, October 08, 2003 11:44 PM > > > >>>>> To: simple@ietf.org > > > >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays > > > >>>>> > > > >>>>> > > > >>>>> I just realized that we had one more subject brought up in > > > >>>>> Vienna where > > > >>>>> we decided to "take it to the list". Which of course has not > > > >>>>> yet happened. > > > >>>>> > > > >>>>> The question was brought up that, in the previous version of > > > >>>>> MSRP where > > > >>>>> we refreshed state with BIND and VISIT, we had an implied > > > >>>>> mechanism by > > > >>>>> which a relay could shed load for shutdown. That is, is > > > >>>>> starts refusing > > > >>>>> refreshes until all sessions have expired. > > > >>>>> > > > >>>>> Since we have moved to a keep-alive approach rather than > > > >>>> > > > >>>> > > > >>> the refresh > > > >>> > > > >>>>> approach, this is not as clean. A couple of approaches > > > >>>> > > > >>>> > > > >>> come to mind: > > > >>> > > > >>>>> 1) Start refusing _any_ SEND requests, then assume all the > > > >>>>> sessions are > > > >>>>> gone when the timeout period expires. > > > >>>>> > > > >>>>> 2) Just close all TCP connections and let the endpoints > > > >>>> > > > >>>> > > > >>> deal with it. > > > >>> > > > >>>>> I find myself leaning toward 2, as 1 does not allow the > > > >>>>> endpoints to do > > > >>>>> anything useful on the session anyway. > > > >>>>> > > > >>>>> Thoughts? > > > >>>>> > > > >>>>> Ben. > > > >>>>> > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> Simple mailing list > > > >>>>> Simple@ietf.org > > > >>>>> https://www1.ietf.org/mailman/listinfo/simple > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Simple mailing list > > > >>>> Simple@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/simple > > > >>> > > > >>> > > > >> > > > >> _______________________________________________ > > > >> Simple mailing list > > > >> Simple@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/simple > > > >> > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 14:27:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18931; Mon, 13 Oct 2003 14:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97PZ-0006TJ-00; Mon, 13 Oct 2003 14:27:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A97PY-0006TG-00; Mon, 13 Oct 2003 14:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97PJ-0008O3-IX; Mon, 13 Oct 2003 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97OK-0008Mm-9K for simple@optimus.ietf.org; Mon, 13 Oct 2003 14:26:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18884 for ; Mon, 13 Oct 2003 14:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97OH-0006SQ-00 for simple@ietf.org; Mon, 13 Oct 2003 14:25:57 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A97OG-0006SN-00 for simple@ietf.org; Mon, 13 Oct 2003 14:25:56 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9DIPTeY037492; Mon, 13 Oct 2003 13:25:40 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8AEE16.4060206@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 13:25:26 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, October 10, 2003 11:47 PM >>To: Paul Kyzivat >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >>simple@ietf.org >>Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >>Paul Kyzivat wrote: >> >> >>> >>>Ben Campbell wrote: >>> >>> >>>>That is not far from the same thing, since if there was a >> >>single idle >> >>>>session, it will take up to 1 timeout for each endpoint to send a >>>>request that the relay could respond to. >>>> >>>>But my point was, for Paul's scenario, it is not >> >>neccessary to wait >> >>>>for idle endpoints to get around to sending a request. You >> >>just have >> >>>>to wait long enough so that it is very unlikely that any >> >>transactions >> >>>>are still in play. A small number of minutes should be >> >>plenty of time. >> >>> >>>Hmm. How does waiting decrease the likelihood that messages >> >>are still in >> >>>play? Even though there have been no messages in the last N >> >>minutes, one >> >>>could just have been sent. >>> >>>To be sure there are none, I think you must in general wait for the >>>timeout interval if the stream is idle. But if the stream >> >>is active, you >> >>>can just start sending the magic error code to every >> >>received message >> >>>for awhile, with the understanding that a sending, upon >> >>receiving this >> >>>code, will no longer send messages on the stream. Then, >> >>after enough >> >>>time has passed for all messages in the pipeline to have >> >>been received, >> >>>then stream can be shutdown. >> >>If the goal is to make the relay notifies all endpoints prior to >>shutting down, then yes, you would have to wait for a full inactivity >>timeout period. But that was not the scenario you subscribed. If the >>relay begins sending 500 responses to any message at time T, >>then it can >>assume that there are no more outstanding transactions at >>T+N. Where N >>is the _transaction_ timout, rather than the inactivity >>timeout. (Now, >>we do not actually define the transaction timeout--it is currently >>listed as some "reasonable period of time." Maybe we need to specify >>that, but I am not sure this particular reason is enough to >>force that >>issue.) >> >>So, at time T+N, the relay can reasonably assume that any transaction >>that was already in progress when it started sending the 500s >>has either >>completed or timed out. I suppose there could be requests >>that are still >>sitting in the endpoints TCP send buffer and never get a 500, >>but that >>would be a pretty small percentages of messages overall. >> >> >>>To speed up shutdown of an inactive stream I think either >> >>the inactivity >> >>>timeout needs to be reduced, or else there needs to be a special >>>graceful close message that can be sent. >> >>I gather that you are looking for a "perfectly" graceful >>shutdown, that >>guarantees that the endpoint will know for sure that a given >>message has >>been delivered or not delivered. I accept that it may be polite >>behavior to minimize messages in "limbo". But nothing in MSRP >>guarantees >>that a SEND transaction that times out without a response has not >>actually been delivered. We can only guarantee that, if you get a >>successful response back, the message _has_ been delivered. >> >>So I think it is reasonable to suggest that a relay wait a couple of >>minutes after it stops relaying requests before it actually >>shuts down. >>I don't think it is reasonable to ask it to wait 12 minutes, >>and I don't >>think that this particular issue provides sufficient motivation to >>reduce the idle timer. >> >>What do others think on this point? > > > > If you don't wait the full idle timeout period, then I don't see the point in waiting a couple of mins before shutting down. It is better to just shut down immediately then. > OK, I think we are talking past each other, because it seems to me there is a big advantage in waiting a "couple of minutes". Again, the point of this waiting period does not have anything to do with notifying endpoints a relay is about to go down. The point is to stop accepting transactions some period before shutting down. This gives us a couple of scenarios: 1) A transaction arrives after we stop accepting new transactions. We immediately reject it with a 5xx response. We do not have to wait for some downstream device to respond. 2) A transaction arrives before we stop accepting new transactions. Because we are waiting a reasonable period between the time we stopped accepting transactions, and the time we shutdown, we make it highly likely that the transaction will either complete, or be timed-out by the sender before we actually shut down. So it seems to me that, if at time T we stop accepting transactions, and at time T + N, where N is approximately a normal transaction timeout, greatly reduces the opportunity for transactions going into the black hole because of a shutdown. (At least for transactions that were not going to get black-holed _anyway_.) Sure, this is not perfect, as at the moment of shutdown, there may be indbound requests in transit at the transport layer. I think we can live with that. > As I said earlier, relay shuts down after the full timeout period, or until it know it has sent 4xx (or 5xx) responses to SEND requests sent by all the participants in all session. Whichever is reached first. In this way, you guarantee that either the clients have been notified of such shutdown on that the clients have timed out themselves anyway. I don't think advance client knowledge that the relay is going to shutdown is a requirement. The client will discover this when the relay closes the TCP connection. > > /Hisham > > > > >>> Paul >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 14:27:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18970 for ; Mon, 13 Oct 2003 14:27:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97Pe-0008QW-17 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 14:27:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DIRL9S032393 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 14:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97Pc-0008QN-Dw for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 14:27:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18931; Mon, 13 Oct 2003 14:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97PZ-0006TJ-00; Mon, 13 Oct 2003 14:27:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A97PY-0006TG-00; Mon, 13 Oct 2003 14:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97PJ-0008O3-IX; Mon, 13 Oct 2003 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97OK-0008Mm-9K for simple@optimus.ietf.org; Mon, 13 Oct 2003 14:26:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18884 for ; Mon, 13 Oct 2003 14:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97OH-0006SQ-00 for simple@ietf.org; Mon, 13 Oct 2003 14:25:57 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A97OG-0006SN-00 for simple@ietf.org; Mon, 13 Oct 2003 14:25:56 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9DIPTeY037492; Mon, 13 Oct 2003 13:25:40 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8AEE16.4060206@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 13:25:26 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, October 10, 2003 11:47 PM >>To: Paul Kyzivat >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >>simple@ietf.org >>Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >>Paul Kyzivat wrote: >> >> >>> >>>Ben Campbell wrote: >>> >>> >>>>That is not far from the same thing, since if there was a >> >>single idle >> >>>>session, it will take up to 1 timeout for each endpoint to send a >>>>request that the relay could respond to. >>>> >>>>But my point was, for Paul's scenario, it is not >> >>neccessary to wait >> >>>>for idle endpoints to get around to sending a request. You >> >>just have >> >>>>to wait long enough so that it is very unlikely that any >> >>transactions >> >>>>are still in play. A small number of minutes should be >> >>plenty of time. >> >>> >>>Hmm. How does waiting decrease the likelihood that messages >> >>are still in >> >>>play? Even though there have been no messages in the last N >> >>minutes, one >> >>>could just have been sent. >>> >>>To be sure there are none, I think you must in general wait for the >>>timeout interval if the stream is idle. But if the stream >> >>is active, you >> >>>can just start sending the magic error code to every >> >>received message >> >>>for awhile, with the understanding that a sending, upon >> >>receiving this >> >>>code, will no longer send messages on the stream. Then, >> >>after enough >> >>>time has passed for all messages in the pipeline to have >> >>been received, >> >>>then stream can be shutdown. >> >>If the goal is to make the relay notifies all endpoints prior to >>shutting down, then yes, you would have to wait for a full inactivity >>timeout period. But that was not the scenario you subscribed. If the >>relay begins sending 500 responses to any message at time T, >>then it can >>assume that there are no more outstanding transactions at >>T+N. Where N >>is the _transaction_ timout, rather than the inactivity >>timeout. (Now, >>we do not actually define the transaction timeout--it is currently >>listed as some "reasonable period of time." Maybe we need to specify >>that, but I am not sure this particular reason is enough to >>force that >>issue.) >> >>So, at time T+N, the relay can reasonably assume that any transaction >>that was already in progress when it started sending the 500s >>has either >>completed or timed out. I suppose there could be requests >>that are still >>sitting in the endpoints TCP send buffer and never get a 500, >>but that >>would be a pretty small percentages of messages overall. >> >> >>>To speed up shutdown of an inactive stream I think either >> >>the inactivity >> >>>timeout needs to be reduced, or else there needs to be a special >>>graceful close message that can be sent. >> >>I gather that you are looking for a "perfectly" graceful >>shutdown, that >>guarantees that the endpoint will know for sure that a given >>message has >>been delivered or not delivered. I accept that it may be polite >>behavior to minimize messages in "limbo". But nothing in MSRP >>guarantees >>that a SEND transaction that times out without a response has not >>actually been delivered. We can only guarantee that, if you get a >>successful response back, the message _has_ been delivered. >> >>So I think it is reasonable to suggest that a relay wait a couple of >>minutes after it stops relaying requests before it actually >>shuts down. >>I don't think it is reasonable to ask it to wait 12 minutes, >>and I don't >>think that this particular issue provides sufficient motivation to >>reduce the idle timer. >> >>What do others think on this point? > > > > If you don't wait the full idle timeout period, then I don't see the point in waiting a couple of mins before shutting down. It is better to just shut down immediately then. > OK, I think we are talking past each other, because it seems to me there is a big advantage in waiting a "couple of minutes". Again, the point of this waiting period does not have anything to do with notifying endpoints a relay is about to go down. The point is to stop accepting transactions some period before shutting down. This gives us a couple of scenarios: 1) A transaction arrives after we stop accepting new transactions. We immediately reject it with a 5xx response. We do not have to wait for some downstream device to respond. 2) A transaction arrives before we stop accepting new transactions. Because we are waiting a reasonable period between the time we stopped accepting transactions, and the time we shutdown, we make it highly likely that the transaction will either complete, or be timed-out by the sender before we actually shut down. So it seems to me that, if at time T we stop accepting transactions, and at time T + N, where N is approximately a normal transaction timeout, greatly reduces the opportunity for transactions going into the black hole because of a shutdown. (At least for transactions that were not going to get black-holed _anyway_.) Sure, this is not perfect, as at the moment of shutdown, there may be indbound requests in transit at the transport layer. I think we can live with that. > As I said earlier, relay shuts down after the full timeout period, or until it know it has sent 4xx (or 5xx) responses to SEND requests sent by all the participants in all session. Whichever is reached first. In this way, you guarantee that either the clients have been notified of such shutdown on that the clients have timed out themselves anyway. I don't think advance client knowledge that the relay is going to shutdown is a requirement. The client will discover this when the relay closes the TCP connection. > > /Hisham > > > > >>> Paul >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 15:02:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20474; Mon, 13 Oct 2003 15:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97yE-0006qi-00; Mon, 13 Oct 2003 15:03:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A97yE-0006qf-00; Mon, 13 Oct 2003 15:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97y9-0001q8-M1; Mon, 13 Oct 2003 15:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97xI-0001ox-OH for simple@optimus.ietf.org; Mon, 13 Oct 2003 15:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20437 for ; Mon, 13 Oct 2003 15:01:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97xF-0006pq-00 for simple@ietf.org; Mon, 13 Oct 2003 15:02:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A97xF-0006oz-00 for simple@ietf.org; Mon, 13 Oct 2003 15:02:05 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2003 12:02:17 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DJ1VSw018736; Mon, 13 Oct 2003 12:01:32 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC35362; Mon, 13 Oct 2003 15:01:31 -0400 (EDT) Message-ID: <3F8AF68A.5050700@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 15:01:30 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > OK, I think we are talking past each other, because it seems to me there > is a big advantage in waiting a "couple of minutes". Again, the point of > this waiting period does not have anything to do with notifying > endpoints a relay is about to go down. The point is to stop accepting > transactions some period before shutting down. This gives us a couple of > scenarios: > > 1) A transaction arrives after we stop accepting new transactions. We > immediately reject it with a 5xx response. We do not have to wait for > some downstream device to respond. > > 2) A transaction arrives before we stop accepting new transactions. > Because we are waiting a reasonable period between the time we stopped > accepting transactions, and the time we shutdown, we make it highly > likely that the transaction will either complete, or be timed-out by the > sender before we actually shut down. > > So it seems to me that, if at time T we stop accepting transactions, and > at time T + N, where N is approximately a normal transaction timeout, > greatly reduces the opportunity for transactions going into the black > hole because of a shutdown. (At least for transactions that were not > going to get black-holed _anyway_.) > > Sure, this is not perfect, as at the moment of shutdown, there may be > indbound requests in transit at the transport layer. I think we can live > with that. Why is that a good thing to live with? It means that every time some big relay is shutdown for maintenance, some number of people will see one of their messages duplicated. Many of those people will file a bug report the first time this happens to them. All of them will consider the service buggy as a result. Because of the bugginess, applications will either decide some other transport is better, or else will try to work something into the endpoint to detect the repeated message. So I think we either need to prevent the duplicated messages (without introducing lost messages) or else we need to specify how the recovery works, including supression of duplicates. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 15:03:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20516 for ; Mon, 13 Oct 2003 15:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97yI-0001s9-F9 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 15:03:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DJ3AJn007191 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 15:03:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97yI-0001ru-7C for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 15:03:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20474; Mon, 13 Oct 2003 15:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97yE-0006qi-00; Mon, 13 Oct 2003 15:03:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A97yE-0006qf-00; Mon, 13 Oct 2003 15:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97y9-0001q8-M1; Mon, 13 Oct 2003 15:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A97xI-0001ox-OH for simple@optimus.ietf.org; Mon, 13 Oct 2003 15:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20437 for ; Mon, 13 Oct 2003 15:01:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A97xF-0006pq-00 for simple@ietf.org; Mon, 13 Oct 2003 15:02:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A97xF-0006oz-00 for simple@ietf.org; Mon, 13 Oct 2003 15:02:05 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2003 12:02:17 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DJ1VSw018736; Mon, 13 Oct 2003 12:01:32 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC35362; Mon, 13 Oct 2003 15:01:31 -0400 (EDT) Message-ID: <3F8AF68A.5050700@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 15:01:30 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > OK, I think we are talking past each other, because it seems to me there > is a big advantage in waiting a "couple of minutes". Again, the point of > this waiting period does not have anything to do with notifying > endpoints a relay is about to go down. The point is to stop accepting > transactions some period before shutting down. This gives us a couple of > scenarios: > > 1) A transaction arrives after we stop accepting new transactions. We > immediately reject it with a 5xx response. We do not have to wait for > some downstream device to respond. > > 2) A transaction arrives before we stop accepting new transactions. > Because we are waiting a reasonable period between the time we stopped > accepting transactions, and the time we shutdown, we make it highly > likely that the transaction will either complete, or be timed-out by the > sender before we actually shut down. > > So it seems to me that, if at time T we stop accepting transactions, and > at time T + N, where N is approximately a normal transaction timeout, > greatly reduces the opportunity for transactions going into the black > hole because of a shutdown. (At least for transactions that were not > going to get black-holed _anyway_.) > > Sure, this is not perfect, as at the moment of shutdown, there may be > indbound requests in transit at the transport layer. I think we can live > with that. Why is that a good thing to live with? It means that every time some big relay is shutdown for maintenance, some number of people will see one of their messages duplicated. Many of those people will file a bug report the first time this happens to them. All of them will consider the service buggy as a result. Because of the bugginess, applications will either decide some other transport is better, or else will try to work something into the endpoint to detect the repeated message. So I think we either need to prevent the duplicated messages (without introducing lost messages) or else we need to specify how the recovery works, including supression of duplicates. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 16:22:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26153; Mon, 13 Oct 2003 16:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99Cr-0000I6-00; Mon, 13 Oct 2003 16:22:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A99Cr-0000I3-00; Mon, 13 Oct 2003 16:22:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Cb-0006ss-Bp; Mon, 13 Oct 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99CU-0006sZ-OR for simple@optimus.ietf.org; Mon, 13 Oct 2003 16:21:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26138 for ; Mon, 13 Oct 2003 16:21:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99CS-0000Hm-00 for simple@ietf.org; Mon, 13 Oct 2003 16:21:52 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A99CQ-0000Hj-00 for simple@ietf.org; Mon, 13 Oct 2003 16:21:51 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9DKLXeY047010; Mon, 13 Oct 2003 15:21:40 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8B0949.3060204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> In-Reply-To: <3F8AF68A.5050700@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 15:21:29 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> OK, I think we are talking past each other, because it seems to me >> there is a big advantage in waiting a "couple of minutes". Again, the >> point of this waiting period does not have anything to do with >> notifying endpoints a relay is about to go down. The point is to stop >> accepting transactions some period before shutting down. This gives us >> a couple of scenarios: >> >> 1) A transaction arrives after we stop accepting new transactions. We >> immediately reject it with a 5xx response. We do not have to wait for >> some downstream device to respond. >> >> 2) A transaction arrives before we stop accepting new transactions. >> Because we are waiting a reasonable period between the time we stopped >> accepting transactions, and the time we shutdown, we make it highly >> likely that the transaction will either complete, or be timed-out by >> the sender before we actually shut down. >> >> So it seems to me that, if at time T we stop accepting transactions, >> and at time T + N, where N is approximately a normal transaction >> timeout, greatly reduces the opportunity for transactions going into >> the black hole because of a shutdown. (At least for transactions that >> were not going to get black-holed _anyway_.) >> >> Sure, this is not perfect, as at the moment of shutdown, there may be >> indbound requests in transit at the transport layer. I think we can >> live with that. > > > Why is that a good thing to live with? It means that every time some big > relay is shutdown for maintenance, some number of people will see one of > their messages duplicated. Many of those people will file a bug report > the first time this happens to them. All of them will consider the > service buggy as a result. I did not say it was good. I said I think we can live with it. That is not the same thing. It seems to me we have 4 choices: 1) Live with the potential for duplicate deliveries when a logical conversation transitions from one session to another in a short time period. Note that this can happen without relays being involved at all. 2) Require any hosting device that wishes to end a session wait either until connected devices send a request, so that we can send a response indicating that we are shutting down, or until an inactivity timeout occurs. 3) Allow relays to originate a message saying the session is going down. 4) Create a cross-session duplicate supression mechanism. 3) and 4) seem awfully heavy-weight for the value they create. 2) either puts a big burden on hosting device shutdown time, or requires us to significantly shorten the timer value--which, as has been discussed at length on this list, is also heavy-weight. Of these choices, I prefer option 1. > > Because of the bugginess, applications will either decide some other > transport is better, or else will try to work something into the > endpoint to detect the repeated message. > > So I think we either need to prevent the duplicated messages (without > introducing lost messages) or else we need to specify how the recovery > works, including supression of duplicates. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 16:22:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26218 for ; Mon, 13 Oct 2003 16:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Cu-0006ug-Bn for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 16:22:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DKMKUT026570 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 16:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Cu-0006uT-88 for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 16:22:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26153; Mon, 13 Oct 2003 16:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99Cr-0000I6-00; Mon, 13 Oct 2003 16:22:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A99Cr-0000I3-00; Mon, 13 Oct 2003 16:22:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Cb-0006ss-Bp; Mon, 13 Oct 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99CU-0006sZ-OR for simple@optimus.ietf.org; Mon, 13 Oct 2003 16:21:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26138 for ; Mon, 13 Oct 2003 16:21:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99CS-0000Hm-00 for simple@ietf.org; Mon, 13 Oct 2003 16:21:52 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A99CQ-0000Hj-00 for simple@ietf.org; Mon, 13 Oct 2003 16:21:51 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9DKLXeY047010; Mon, 13 Oct 2003 15:21:40 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8B0949.3060204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> In-Reply-To: <3F8AF68A.5050700@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 15:21:29 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> OK, I think we are talking past each other, because it seems to me >> there is a big advantage in waiting a "couple of minutes". Again, the >> point of this waiting period does not have anything to do with >> notifying endpoints a relay is about to go down. The point is to stop >> accepting transactions some period before shutting down. This gives us >> a couple of scenarios: >> >> 1) A transaction arrives after we stop accepting new transactions. We >> immediately reject it with a 5xx response. We do not have to wait for >> some downstream device to respond. >> >> 2) A transaction arrives before we stop accepting new transactions. >> Because we are waiting a reasonable period between the time we stopped >> accepting transactions, and the time we shutdown, we make it highly >> likely that the transaction will either complete, or be timed-out by >> the sender before we actually shut down. >> >> So it seems to me that, if at time T we stop accepting transactions, >> and at time T + N, where N is approximately a normal transaction >> timeout, greatly reduces the opportunity for transactions going into >> the black hole because of a shutdown. (At least for transactions that >> were not going to get black-holed _anyway_.) >> >> Sure, this is not perfect, as at the moment of shutdown, there may be >> indbound requests in transit at the transport layer. I think we can >> live with that. > > > Why is that a good thing to live with? It means that every time some big > relay is shutdown for maintenance, some number of people will see one of > their messages duplicated. Many of those people will file a bug report > the first time this happens to them. All of them will consider the > service buggy as a result. I did not say it was good. I said I think we can live with it. That is not the same thing. It seems to me we have 4 choices: 1) Live with the potential for duplicate deliveries when a logical conversation transitions from one session to another in a short time period. Note that this can happen without relays being involved at all. 2) Require any hosting device that wishes to end a session wait either until connected devices send a request, so that we can send a response indicating that we are shutting down, or until an inactivity timeout occurs. 3) Allow relays to originate a message saying the session is going down. 4) Create a cross-session duplicate supression mechanism. 3) and 4) seem awfully heavy-weight for the value they create. 2) either puts a big burden on hosting device shutdown time, or requires us to significantly shorten the timer value--which, as has been discussed at length on this list, is also heavy-weight. Of these choices, I prefer option 1. > > Because of the bugginess, applications will either decide some other > transport is better, or else will try to work something into the > endpoint to detect the repeated message. > > So I think we either need to prevent the duplicated messages (without > introducing lost messages) or else we need to specify how the recovery > works, including supression of duplicates. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 17:19:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29711; Mon, 13 Oct 2003 17:19:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9A5s-0001Sb-00; Mon, 13 Oct 2003 17:19:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9A5s-0001SY-00; Mon, 13 Oct 2003 17:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9A5l-0001DU-Kb; Mon, 13 Oct 2003 17:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9A5d-0001DB-Ul for simple@optimus.ietf.org; Mon, 13 Oct 2003 17:18:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29705 for ; Mon, 13 Oct 2003 17:18:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9A5b-0001SO-00 for simple@ietf.org; Mon, 13 Oct 2003 17:18:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A9A5b-0001S2-00 for simple@ietf.org; Mon, 13 Oct 2003 17:18:51 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2003 14:19:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DLIISw017078; Mon, 13 Oct 2003 14:18:18 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC47955; Mon, 13 Oct 2003 17:18:17 -0400 (EDT) Message-ID: <3F8B1699.4030104@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 17:18:17 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > I did not say it was good. I said I think we can live with it. That is > not the same thing. > > It seems to me we have 4 choices: > > 1) Live with the potential for duplicate deliveries when a logical > conversation transitions from one session to another in a short time > period. Note that this can happen without relays being involved at all. > > 2) Require any hosting device that wishes to end a session wait either > until connected devices send a request, so that we can send a response > indicating that we are shutting down, or until an inactivity timeout > occurs. > > 3) Allow relays to originate a message saying the session is going down. > > 4) Create a cross-session duplicate supression mechanism. > > 3) and 4) seem awfully heavy-weight for the value they create. 2) either > puts a big burden on hosting device shutdown time, or requires us to > significantly shorten the timer value--which, as has been discussed at > length on this list, is also heavy-weight. > > Of these choices, I prefer option 1. I think you managed to summarize the choices quite well. I prefer either 2, or 4. Of those, 2 is the simpler, and I would be ok with reducing the timer value to make it responsive enough. OTOH, 4 also works in the case of a server crashing ungracefully, which 2 won't cover. I think 1 is a non-starter. We are all geeks, and can be tolerant of such misbehavior if we understand why it is happening. Others will not be so tolerant. They especially won't be tolerant if the message happens to be their 5gb movie. Now that I think about it, the 5gb message may be a reason to prefer 4. (Or 3): I don't think 2 works for that case. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 17:19:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29738 for ; Mon, 13 Oct 2003 17:19:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9A5w-0001FH-2b for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 17:19:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DLJCRt004788 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 17:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9A5v-0001F9-SE for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 17:19:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29711; Mon, 13 Oct 2003 17:19:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9A5s-0001Sb-00; Mon, 13 Oct 2003 17:19:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9A5s-0001SY-00; Mon, 13 Oct 2003 17:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9A5l-0001DU-Kb; Mon, 13 Oct 2003 17:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9A5d-0001DB-Ul for simple@optimus.ietf.org; Mon, 13 Oct 2003 17:18:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29705 for ; Mon, 13 Oct 2003 17:18:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9A5b-0001SO-00 for simple@ietf.org; Mon, 13 Oct 2003 17:18:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A9A5b-0001S2-00 for simple@ietf.org; Mon, 13 Oct 2003 17:18:51 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2003 14:19:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DLIISw017078; Mon, 13 Oct 2003 14:18:18 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC47955; Mon, 13 Oct 2003 17:18:17 -0400 (EDT) Message-ID: <3F8B1699.4030104@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 17:18:17 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > I did not say it was good. I said I think we can live with it. That is > not the same thing. > > It seems to me we have 4 choices: > > 1) Live with the potential for duplicate deliveries when a logical > conversation transitions from one session to another in a short time > period. Note that this can happen without relays being involved at all. > > 2) Require any hosting device that wishes to end a session wait either > until connected devices send a request, so that we can send a response > indicating that we are shutting down, or until an inactivity timeout > occurs. > > 3) Allow relays to originate a message saying the session is going down. > > 4) Create a cross-session duplicate supression mechanism. > > 3) and 4) seem awfully heavy-weight for the value they create. 2) either > puts a big burden on hosting device shutdown time, or requires us to > significantly shorten the timer value--which, as has been discussed at > length on this list, is also heavy-weight. > > Of these choices, I prefer option 1. I think you managed to summarize the choices quite well. I prefer either 2, or 4. Of those, 2 is the simpler, and I would be ok with reducing the timer value to make it responsive enough. OTOH, 4 also works in the case of a server crashing ungracefully, which 2 won't cover. I think 1 is a non-starter. We are all geeks, and can be tolerant of such misbehavior if we understand why it is happening. Others will not be so tolerant. They especially won't be tolerant if the message happens to be their 5gb movie. Now that I think about it, the 5gb message may be a reason to prefer 4. (Or 3): I don't think 2 works for that case. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 19:14:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04698; Mon, 13 Oct 2003 19:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9BtB-0002py-00; Mon, 13 Oct 2003 19:14:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9BtB-0002pv-00; Mon, 13 Oct 2003 19:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Bt3-0006TG-2C; Mon, 13 Oct 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Bs5-0006SG-A2 for simple@optimus.ietf.org; Mon, 13 Oct 2003 19:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04665 for ; Mon, 13 Oct 2003 19:12:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Bs3-0002oS-00 for simple@ietf.org; Mon, 13 Oct 2003 19:12:59 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Bs3-0002o6-00 for simple@ietf.org; Mon, 13 Oct 2003 19:12:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9DNBSd06973; Mon, 13 Oct 2003 18:11:28 -0500 Subject: Re: [Simple] MSRP: Administrative shutdown of relays From: Robert Sparks To: Paul Kyzivat Cc: Ben Campbell , Hisham Khartabil , cboulton@ubiquity.net, simple@ietf.org In-Reply-To: <3F8B1699.4030104@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> <3F8B1699.4030104@cisco.com> Content-Type: text/plain Message-Id: <1066086684.937.60.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 18:11:24 -0500 Content-Transfer-Encoding: 7bit (as non-chair). I think the edge conditions we are talking about here are sufficiently edge that we should document them and not take on the burden of trying to prevent them. I prefer option 1. RjS On Mon, 2003-10-13 at 16:18, Paul Kyzivat wrote: > Ben Campbell wrote: > > > > I did not say it was good. I said I think we can live with it. That is > > not the same thing. > > > > It seems to me we have 4 choices: > > > > 1) Live with the potential for duplicate deliveries when a logical > > conversation transitions from one session to another in a short time > > period. Note that this can happen without relays being involved at all. > > > > 2) Require any hosting device that wishes to end a session wait either > > until connected devices send a request, so that we can send a response > > indicating that we are shutting down, or until an inactivity timeout > > occurs. > > > > 3) Allow relays to originate a message saying the session is going down. > > > > 4) Create a cross-session duplicate supression mechanism. > > > > 3) and 4) seem awfully heavy-weight for the value they create. 2) either > > puts a big burden on hosting device shutdown time, or requires us to > > significantly shorten the timer value--which, as has been discussed at > > length on this list, is also heavy-weight. > > > > Of these choices, I prefer option 1. > > I think you managed to summarize the choices quite well. > > I prefer either 2, or 4. Of those, 2 is the simpler, and I would be ok > with reducing the timer value to make it responsive enough. OTOH, 4 also > works in the case of a server crashing ungracefully, which 2 won't cover. > > I think 1 is a non-starter. We are all geeks, and can be tolerant of > such misbehavior if we understand why it is happening. Others will not > be so tolerant. They especially won't be tolerant if the message happens > to be their 5gb movie. > > Now that I think about it, the 5gb message may be a reason to prefer 4. > (Or 3): I don't think 2 works for that case. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 19:14:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04721 for ; Mon, 13 Oct 2003 19:14:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9BtD-0006U6-Up for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 19:14:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DNEBvw024920 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 19:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9BtD-0006Tr-RV for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 19:14:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04698; Mon, 13 Oct 2003 19:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9BtB-0002py-00; Mon, 13 Oct 2003 19:14:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9BtB-0002pv-00; Mon, 13 Oct 2003 19:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Bt3-0006TG-2C; Mon, 13 Oct 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Bs5-0006SG-A2 for simple@optimus.ietf.org; Mon, 13 Oct 2003 19:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04665 for ; Mon, 13 Oct 2003 19:12:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Bs3-0002oS-00 for simple@ietf.org; Mon, 13 Oct 2003 19:12:59 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Bs3-0002o6-00 for simple@ietf.org; Mon, 13 Oct 2003 19:12:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9DNBSd06973; Mon, 13 Oct 2003 18:11:28 -0500 Subject: Re: [Simple] MSRP: Administrative shutdown of relays From: Robert Sparks To: Paul Kyzivat Cc: Ben Campbell , Hisham Khartabil , cboulton@ubiquity.net, simple@ietf.org In-Reply-To: <3F8B1699.4030104@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> <3F8B1699.4030104@cisco.com> Content-Type: text/plain Message-Id: <1066086684.937.60.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 18:11:24 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (as non-chair). I think the edge conditions we are talking about here are sufficiently edge that we should document them and not take on the burden of trying to prevent them. I prefer option 1. RjS On Mon, 2003-10-13 at 16:18, Paul Kyzivat wrote: > Ben Campbell wrote: > > > > I did not say it was good. I said I think we can live with it. That is > > not the same thing. > > > > It seems to me we have 4 choices: > > > > 1) Live with the potential for duplicate deliveries when a logical > > conversation transitions from one session to another in a short time > > period. Note that this can happen without relays being involved at all. > > > > 2) Require any hosting device that wishes to end a session wait either > > until connected devices send a request, so that we can send a response > > indicating that we are shutting down, or until an inactivity timeout > > occurs. > > > > 3) Allow relays to originate a message saying the session is going down. > > > > 4) Create a cross-session duplicate supression mechanism. > > > > 3) and 4) seem awfully heavy-weight for the value they create. 2) either > > puts a big burden on hosting device shutdown time, or requires us to > > significantly shorten the timer value--which, as has been discussed at > > length on this list, is also heavy-weight. > > > > Of these choices, I prefer option 1. > > I think you managed to summarize the choices quite well. > > I prefer either 2, or 4. Of those, 2 is the simpler, and I would be ok > with reducing the timer value to make it responsive enough. OTOH, 4 also > works in the case of a server crashing ungracefully, which 2 won't cover. > > I think 1 is a non-starter. We are all geeks, and can be tolerant of > such misbehavior if we understand why it is happening. Others will not > be so tolerant. They especially won't be tolerant if the message happens > to be their 5gb movie. > > Now that I think about it, the 5gb message may be a reason to prefer 4. > (Or 3): I don't think 2 works for that case. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 19:26:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05056; Mon, 13 Oct 2003 19:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9C5g-0002yB-00; Mon, 13 Oct 2003 19:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9C5g-0002y8-00; Mon, 13 Oct 2003 19:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9C5c-00075t-Hb; Mon, 13 Oct 2003 19:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9C4f-00073v-AI for simple@optimus.ietf.org; Mon, 13 Oct 2003 19:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05037 for ; Mon, 13 Oct 2003 19:25:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9C4d-0002xZ-00 for simple@ietf.org; Mon, 13 Oct 2003 19:25:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A9C4c-0002xS-00 for simple@ietf.org; Mon, 13 Oct 2003 19:25:59 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9DNPdeY062063; Mon, 13 Oct 2003 18:25:45 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8B346E.8040607@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> In-Reply-To: <3F8B0949.3060204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 18:25:34 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: [...] > > I did not say it was good. I said I think we can live with it. That is > not the same thing. > > It seems to me we have 4 choices: > > 1) Live with the potential for duplicate deliveries when a logical > conversation transitions from one session to another in a short time > period. Note that this can happen without relays being involved at all. > I did, btw, intend option 1 to have a long enough waiting period so that any transactions that were in play when we decided to shutdown have time to complete. I just failed to actually type it. :-) > 2) Require any hosting device that wishes to end a session wait either > until connected devices send a request, so that we can send a response > indicating that we are shutting down, or until an inactivity timeout > occurs. > > 3) Allow relays to originate a message saying the session is going down. > > 4) Create a cross-session duplicate supression mechanism. > > 3) and 4) seem awfully heavy-weight for the value they create. 2) either > puts a big burden on hosting device shutdown time, or requires us to > significantly shorten the timer value--which, as has been discussed at > length on this list, is also heavy-weight. > > Of these choices, I prefer option 1. > >> >> Because of the bugginess, applications will either decide some other >> transport is better, or else will try to work something into the >> endpoint to detect the repeated message. >> >> So I think we either need to prevent the duplicated messages (without >> introducing lost messages) or else we need to specify how the recovery >> works, including supression of duplicates. >> >> Paul > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 19:27:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05076 for ; Mon, 13 Oct 2003 19:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9C5j-00077d-0w for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 19:27:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DNR7kS027375 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 19:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9C5i-00077S-S0 for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 19:27:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05056; Mon, 13 Oct 2003 19:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9C5g-0002yB-00; Mon, 13 Oct 2003 19:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9C5g-0002y8-00; Mon, 13 Oct 2003 19:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9C5c-00075t-Hb; Mon, 13 Oct 2003 19:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9C4f-00073v-AI for simple@optimus.ietf.org; Mon, 13 Oct 2003 19:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05037 for ; Mon, 13 Oct 2003 19:25:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9C4d-0002xZ-00 for simple@ietf.org; Mon, 13 Oct 2003 19:25:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A9C4c-0002xS-00 for simple@ietf.org; Mon, 13 Oct 2003 19:25:59 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9DNPdeY062063; Mon, 13 Oct 2003 18:25:45 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8B346E.8040607@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> In-Reply-To: <3F8B0949.3060204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 18:25:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: [...] > > I did not say it was good. I said I think we can live with it. That is > not the same thing. > > It seems to me we have 4 choices: > > 1) Live with the potential for duplicate deliveries when a logical > conversation transitions from one session to another in a short time > period. Note that this can happen without relays being involved at all. > I did, btw, intend option 1 to have a long enough waiting period so that any transactions that were in play when we decided to shutdown have time to complete. I just failed to actually type it. :-) > 2) Require any hosting device that wishes to end a session wait either > until connected devices send a request, so that we can send a response > indicating that we are shutting down, or until an inactivity timeout > occurs. > > 3) Allow relays to originate a message saying the session is going down. > > 4) Create a cross-session duplicate supression mechanism. > > 3) and 4) seem awfully heavy-weight for the value they create. 2) either > puts a big burden on hosting device shutdown time, or requires us to > significantly shorten the timer value--which, as has been discussed at > length on this list, is also heavy-weight. > > Of these choices, I prefer option 1. > >> >> Because of the bugginess, applications will either decide some other >> transport is better, or else will try to work something into the >> endpoint to detect the repeated message. >> >> So I think we either need to prevent the duplicated messages (without >> introducing lost messages) or else we need to specify how the recovery >> works, including supression of duplicates. >> >> Paul > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 13 19:31:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05234; Mon, 13 Oct 2003 19:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9CAU-00032V-00; Mon, 13 Oct 2003 19:32:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9CAT-00032S-00; Mon, 13 Oct 2003 19:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CAT-0007MN-6t; Mon, 13 Oct 2003 19:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CAO-0007Ly-0Z for simple@optimus.ietf.org; Mon, 13 Oct 2003 19:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05223 for ; Mon, 13 Oct 2003 19:31:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9CAM-00032E-00 for simple@ietf.org; Mon, 13 Oct 2003 19:31:54 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A9CAL-00031D-00 for simple@ietf.org; Mon, 13 Oct 2003 19:31:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9DNVMd07298 for ; Mon, 13 Oct 2003 18:31:22 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1066087878.948.80.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 18:31:19 -0500 Content-Transfer-Encoding: 7bit If you have not been reading the Administrative shutdown of relays thread, the following provides a summary of the possible paths the thread has explored: In interests of progress _before_ Minnesota, I would like to get input from people other than the 3 primary participants in the tread as to what they believe is important for us to work on. So, I am calling an electronic hum. Respond to list or privately to me if you prefer. The questions called are: One: Do you believe it is important for the document to discuss administrative shutdown of relays. Two: (answer only if you answer Yes to question One). How much scope creep are we willing to take on? The options below are listed in increasing scope creep order. Please respond with which option you would like to see pursued. Please respond to this call no later than Wed 10/15. RjS -----Forwarded Message----- > From: Ben Campbell > > It seems to me we have 4 choices: > > 1) Live with the potential for duplicate deliveries when a logical > conversation transitions from one session to another in a short time > period. Note that this can happen without relays being involved at all. This potential can be bounded by shorter than inactivity timeout delays (specifically watiting for transactions already in progress to complete). > > 2) Require any hosting device that wishes to end a session wait either > until connected devices send a request, so that we can send a response > indicating that we are shutting down, or until an inactivity timeout occurs. > > 3) Allow relays to originate a message saying the session is going down. > > 4) Create a cross-session duplicate supression mechanism. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 13 19:32:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05270 for ; Mon, 13 Oct 2003 19:32:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CAW-0007NA-GB for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 19:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DNW4c1028334 for simple-archive@odin.ietf.org; Mon, 13 Oct 2003 19:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CAW-0007Mv-Bx for simple-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 19:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05234; Mon, 13 Oct 2003 19:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9CAU-00032V-00; Mon, 13 Oct 2003 19:32:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9CAT-00032S-00; Mon, 13 Oct 2003 19:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CAT-0007MN-6t; Mon, 13 Oct 2003 19:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9CAO-0007Ly-0Z for simple@optimus.ietf.org; Mon, 13 Oct 2003 19:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05223 for ; Mon, 13 Oct 2003 19:31:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9CAM-00032E-00 for simple@ietf.org; Mon, 13 Oct 2003 19:31:54 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A9CAL-00031D-00 for simple@ietf.org; Mon, 13 Oct 2003 19:31:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9DNVMd07298 for ; Mon, 13 Oct 2003 18:31:22 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1066087878.948.80.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 18:31:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If you have not been reading the Administrative shutdown of relays thread, the following provides a summary of the possible paths the thread has explored: In interests of progress _before_ Minnesota, I would like to get input from people other than the 3 primary participants in the tread as to what they believe is important for us to work on. So, I am calling an electronic hum. Respond to list or privately to me if you prefer. The questions called are: One: Do you believe it is important for the document to discuss administrative shutdown of relays. Two: (answer only if you answer Yes to question One). How much scope creep are we willing to take on? The options below are listed in increasing scope creep order. Please respond with which option you would like to see pursued. Please respond to this call no later than Wed 10/15. RjS -----Forwarded Message----- > From: Ben Campbell > > It seems to me we have 4 choices: > > 1) Live with the potential for duplicate deliveries when a logical > conversation transitions from one session to another in a short time > period. Note that this can happen without relays being involved at all. This potential can be bounded by shorter than inactivity timeout delays (specifically watiting for transactions already in progress to complete). > > 2) Require any hosting device that wishes to end a session wait either > until connected devices send a request, so that we can send a response > indicating that we are shutting down, or until an inactivity timeout occurs. > > 3) Allow relays to originate a message saying the session is going down. > > 4) Create a cross-session duplicate supression mechanism. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 14 03:33:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28827; Tue, 14 Oct 2003 03:33:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jgz-0006tv-00; Tue, 14 Oct 2003 03:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Jgz-0006ts-00; Tue, 14 Oct 2003 03:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jgw-0003qj-3C; Tue, 14 Oct 2003 03:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jgh-0003qI-3c for simple@optimus.ietf.org; Tue, 14 Oct 2003 03:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28824 for ; Tue, 14 Oct 2003 03:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jge-0006tp-00 for simple@ietf.org; Tue, 14 Oct 2003 03:33:44 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A9Jgd-0006tm-00 for simple@ietf.org; Tue, 14 Oct 2003 03:33:44 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 14 Oct 2003 08:36:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <45730E094814E44488F789C1CDED27AE01E22E07@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOR4ju16eVJkftETQuYEx/WXzB9qAAQtxzw From: "Chris Boulton" To: "Robert Sparks" , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 08:33:52 +0100 Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 14 October 2003 00:31 >To: simple@ietf.org >Subject: [Simple] Chair call for group opinion (was MSRP: Administrative >shutdown of relays) > >If you have not been reading the Administrative shutdown of relays >thread, the following provides a summary of the possible paths the >thread has explored: > >In interests of progress _before_ Minnesota, I would like to get input >from people other than the 3 primary participants in the tread as to >what they believe is important for us to work on. > >So, I am calling an electronic hum. Respond to list or privately to >me if you prefer. The questions called are: > >One: Do you believe it is important for the document to discuss > administrative shutdown of relays. [Chris Boulton] Yes. > >Two: (answer only if you answer Yes to question One). > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. [Chris Boulton] Option 2 is my preferred.=20 > >Please respond to this call no later than Wed 10/15. > >RjS > > > > >-----Forwarded Message----- >> From: Ben Campbell >> >> It seems to me we have 4 choices: >> >> 1) Live with the potential for duplicate deliveries when a logical >> conversation transitions from one session to another in a short time >> period. Note that this can happen without relays being involved at all. >This potential can be bounded by shorter than inactivity timeout delays >(specifically watiting for transactions already in progress to >complete). > >> >> 2) Require any hosting device that wishes to end a session wait either >> until connected devices send a request, so that we can send a response >> indicating that we are shutting down, or until an inactivity timeout >occurs. >> >> 3) Allow relays to originate a message saying the session is going down. >> >> 4) Create a cross-session duplicate supression mechanism. >> > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 14 03:34:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28845 for ; Tue, 14 Oct 2003 03:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jh3-0003rf-7I for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 03:34:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E7Y9tK014849 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 03:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jh2-0003rQ-Ha for simple-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 03:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28827; Tue, 14 Oct 2003 03:33:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jgz-0006tv-00; Tue, 14 Oct 2003 03:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Jgz-0006ts-00; Tue, 14 Oct 2003 03:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jgw-0003qj-3C; Tue, 14 Oct 2003 03:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jgh-0003qI-3c for simple@optimus.ietf.org; Tue, 14 Oct 2003 03:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28824 for ; Tue, 14 Oct 2003 03:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jge-0006tp-00 for simple@ietf.org; Tue, 14 Oct 2003 03:33:44 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A9Jgd-0006tm-00 for simple@ietf.org; Tue, 14 Oct 2003 03:33:44 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 14 Oct 2003 08:36:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <45730E094814E44488F789C1CDED27AE01E22E07@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOR4ju16eVJkftETQuYEx/WXzB9qAAQtxzw From: "Chris Boulton" To: "Robert Sparks" , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 08:33:52 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 14 October 2003 00:31 >To: simple@ietf.org >Subject: [Simple] Chair call for group opinion (was MSRP: Administrative >shutdown of relays) > >If you have not been reading the Administrative shutdown of relays >thread, the following provides a summary of the possible paths the >thread has explored: > >In interests of progress _before_ Minnesota, I would like to get input >from people other than the 3 primary participants in the tread as to >what they believe is important for us to work on. > >So, I am calling an electronic hum. Respond to list or privately to >me if you prefer. The questions called are: > >One: Do you believe it is important for the document to discuss > administrative shutdown of relays. [Chris Boulton] Yes. > >Two: (answer only if you answer Yes to question One). > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. [Chris Boulton] Option 2 is my preferred.=20 > >Please respond to this call no later than Wed 10/15. > >RjS > > > > >-----Forwarded Message----- >> From: Ben Campbell >> >> It seems to me we have 4 choices: >> >> 1) Live with the potential for duplicate deliveries when a logical >> conversation transitions from one session to another in a short time >> period. Note that this can happen without relays being involved at all. >This potential can be bounded by shorter than inactivity timeout delays >(specifically watiting for transactions already in progress to >complete). > >> >> 2) Require any hosting device that wishes to end a session wait either >> until connected devices send a request, so that we can send a response >> indicating that we are shutting down, or until an inactivity timeout >occurs. >> >> 3) Allow relays to originate a message saying the session is going down. >> >> 4) Create a cross-session duplicate supression mechanism. >> > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 14 10:47:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12982; Tue, 14 Oct 2003 10:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QT1-0003cx-00; Tue, 14 Oct 2003 10:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9QT1-0003cs-00; Tue, 14 Oct 2003 10:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QSv-0002fp-El; Tue, 14 Oct 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QSO-0002eR-T8 for simple@optimus.ietf.org; Tue, 14 Oct 2003 10:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12951 for ; Tue, 14 Oct 2003 10:47:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QSM-0003cB-00 for simple@ietf.org; Tue, 14 Oct 2003 10:47:26 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1A9QSL-0003b5-00 for simple@ietf.org; Tue, 14 Oct 2003 10:47:25 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h9EEklYD001594; Tue, 14 Oct 2003 09:46:47 -0500 (CDT) Message-ID: <3F8C0C56.48E61696@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrativeshutdown of relays) References: <1066087878.948.80.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 09:46:46 -0500 Content-Transfer-Encoding: 7bit Hello Robert, 1) I think it is important for the document to discuss administrative shutdown of relays. 2) For the sake of a positive user experience, I'd make the shutdown as graceful as possible. Hence, I'd go for option 3 (Allow relays to originate a message saying the session is going down). Regards, Alex. Robert Sparks wrote: > If you have not been reading the Administrative shutdown of relays > thread, the following provides a summary of the possible paths the > thread has explored: > > In interests of progress _before_ Minnesota, I would like to get input > from people other than the 3 primary participants in the tread as to > what they believe is important for us to work on. > > So, I am calling an electronic hum. Respond to list or privately to > me if you prefer. The questions called are: > > One: Do you believe it is important for the document to discuss > administrative shutdown of relays. > > Two: (answer only if you answer Yes to question One). > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. > > Please respond to this call no later than Wed 10/15. > > RjS > > > -----Forwarded Message----- > > From: Ben Campbell > > > > It seems to me we have 4 choices: > > > > 1) Live with the potential for duplicate deliveries when a logical > > conversation transitions from one session to another in a short time > > period. Note that this can happen without relays being involved at all. > This potential can be bounded by shorter than inactivity timeout delays > (specifically watiting for transactions already in progress to > complete). > > > > > 2) Require any hosting device that wishes to end a session wait either > > until connected devices send a request, so that we can send a response > > indicating that we are shutting down, or until an inactivity timeout occurs. > > > > 3) Allow relays to originate a message saying the session is going down. > > > > 4) Create a cross-session duplicate supression mechanism. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 14 10:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13031 for ; Tue, 14 Oct 2003 10:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QT5-0002ge-1k for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 10:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EEmAwp010324 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 10:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QT4-0002gR-QV for simple-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 10:48:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12982; Tue, 14 Oct 2003 10:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QT1-0003cx-00; Tue, 14 Oct 2003 10:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9QT1-0003cs-00; Tue, 14 Oct 2003 10:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QSv-0002fp-El; Tue, 14 Oct 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QSO-0002eR-T8 for simple@optimus.ietf.org; Tue, 14 Oct 2003 10:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12951 for ; Tue, 14 Oct 2003 10:47:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QSM-0003cB-00 for simple@ietf.org; Tue, 14 Oct 2003 10:47:26 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1A9QSL-0003b5-00 for simple@ietf.org; Tue, 14 Oct 2003 10:47:25 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h9EEklYD001594; Tue, 14 Oct 2003 09:46:47 -0500 (CDT) Message-ID: <3F8C0C56.48E61696@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrativeshutdown of relays) References: <1066087878.948.80.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 09:46:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Robert, 1) I think it is important for the document to discuss administrative shutdown of relays. 2) For the sake of a positive user experience, I'd make the shutdown as graceful as possible. Hence, I'd go for option 3 (Allow relays to originate a message saying the session is going down). Regards, Alex. Robert Sparks wrote: > If you have not been reading the Administrative shutdown of relays > thread, the following provides a summary of the possible paths the > thread has explored: > > In interests of progress _before_ Minnesota, I would like to get input > from people other than the 3 primary participants in the tread as to > what they believe is important for us to work on. > > So, I am calling an electronic hum. Respond to list or privately to > me if you prefer. The questions called are: > > One: Do you believe it is important for the document to discuss > administrative shutdown of relays. > > Two: (answer only if you answer Yes to question One). > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. > > Please respond to this call no later than Wed 10/15. > > RjS > > > -----Forwarded Message----- > > From: Ben Campbell > > > > It seems to me we have 4 choices: > > > > 1) Live with the potential for duplicate deliveries when a logical > > conversation transitions from one session to another in a short time > > period. Note that this can happen without relays being involved at all. > This potential can be bounded by shorter than inactivity timeout delays > (specifically watiting for transactions already in progress to > complete). > > > > > 2) Require any hosting device that wishes to end a session wait either > > until connected devices send a request, so that we can send a response > > indicating that we are shutting down, or until an inactivity timeout occurs. > > > > 3) Allow relays to originate a message saying the session is going down. > > > > 4) Create a cross-session duplicate supression mechanism. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 14 10:58:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13389; Tue, 14 Oct 2003 10:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qdd-0003lo-00; Tue, 14 Oct 2003 10:59:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Qdd-0003ll-00; Tue, 14 Oct 2003 10:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QdZ-0003EQ-JQ; Tue, 14 Oct 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qcl-0003DQ-68 for simple@optimus.ietf.org; Tue, 14 Oct 2003 10:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13370 for ; Tue, 14 Oct 2003 10:58:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qci-0003kw-00 for simple@ietf.org; Tue, 14 Oct 2003 10:58:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Qci-0003kU-00 for simple@ietf.org; Tue, 14 Oct 2003 10:58:08 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2003 08:07:05 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9EEvYeH023985; Tue, 14 Oct 2003 07:57:34 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC93546; Tue, 14 Oct 2003 10:57:33 -0400 (EDT) Message-ID: <3F8C0EDD.2070509@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Ben Campbell , Hisham Khartabil , cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> <3F8B1699.4030104@cisco.com> <1066086684.937.60.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 10:57:33 -0400 Content-Transfer-Encoding: 7bit I thought that Ben's timeout approach didn't work, but after looking at it more closely I have convinced myself that it does work after all. Here is my analysis: With a single relay R, states of a given message are roughly: 1) message in transit from UAC to R 2) message being processed by R 3) message in transit from R to UAS 4) message being processed by UAS 5) response in transit from UAS to R 6) response being processed by R 7) response in transit from R to UAC A UAC that sends a request only knows it is in one of those states, not which one. If the link to the UAC fails while a request is outstanding, the UAC will need to retransmit it on a new connection to ensure it gets through. That will be no problem if the message is in states 1-3, but it will result in message duplication if the message was in states 4-7. The trick is to ensure no messages are in states 4-7. Ben proposed a shutdown strategy where R begins returning an error response for each message arriving at R, while continuing to relay previously received messages and both previously and newly arrived responses. Then, after a waiting period of time TW in this mode, it simply drops all of its connections. Using this strategy, if the times for each state are bounded (T1...T7), and TW > (T2 + ... + T7), then any remaining messages will be in state 1. R can't do anything to prevent messages being in state 1, but it doesn't matter because when the UAC detects the error from shutdown, its recovery action of retransmitting them will be correct and will not result in duplication. This supposes that the durations of the different states are reasonably bounded. This assumtion may be violated for large messages. But perhaps they aren't really a problem. For a large message, if R has not yet transmitted all of it on to UAS, it can simply cease transmitting more of it, and send an error response back to the UAC. The UAS will eventually realize there is an error when the connection to R goes down. As long as it doesn't present the partial message things will be ok. This leaves a case where the message is large and all of it has been transmitted by R. If the latency between R sending the last byte of the message and receiving the response is not reasonably bounded then there is still a problem. This doesn't seem like a likely case. Large responses would also screw things up, but I think we have defined things so that this is never the case. The two relay case is more complex, but it feels like the results will be the same. If nobody can shoot any holes in the above, I am prepared to agree with you that choice 1 is acceptable for relay shutdown, so that choices 2 & 3 have no particular advantage over it. There could still be value to choice 4. It would eliminate any need for waiting and sending errors during shutdown of a relay. In addition, it would also work for failover when a relay crashes. But I'm not sure I want this discussion to go there right now. Paul Robert Sparks wrote: > (as non-chair). > > I think the edge conditions we are talking about here are sufficiently > edge that we should document them and not take on the burden of trying > to prevent them. > > I prefer option 1. > > RjS > > > On Mon, 2003-10-13 at 16:18, Paul Kyzivat wrote: > >>Ben Campbell wrote: >> >>>I did not say it was good. I said I think we can live with it. That is >>>not the same thing. >>> >>>It seems to me we have 4 choices: >>> >>>1) Live with the potential for duplicate deliveries when a logical >>>conversation transitions from one session to another in a short time >>>period. Note that this can happen without relays being involved at all. >>> >>>2) Require any hosting device that wishes to end a session wait either >>>until connected devices send a request, so that we can send a response >>>indicating that we are shutting down, or until an inactivity timeout >>>occurs. >>> >>>3) Allow relays to originate a message saying the session is going down. >>> >>>4) Create a cross-session duplicate supression mechanism. >>> >>>3) and 4) seem awfully heavy-weight for the value they create. 2) either >>>puts a big burden on hosting device shutdown time, or requires us to >>>significantly shorten the timer value--which, as has been discussed at >>>length on this list, is also heavy-weight. >>> >>>Of these choices, I prefer option 1. >> >>I think you managed to summarize the choices quite well. >> >>I prefer either 2, or 4. Of those, 2 is the simpler, and I would be ok >>with reducing the timer value to make it responsive enough. OTOH, 4 also >>works in the case of a server crashing ungracefully, which 2 won't cover. >> >>I think 1 is a non-starter. We are all geeks, and can be tolerant of >>such misbehavior if we understand why it is happening. Others will not >>be so tolerant. They especially won't be tolerant if the message happens >>to be their 5gb movie. >> >>Now that I think about it, the 5gb message may be a reason to prefer 4. >>(Or 3): I don't think 2 works for that case. >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 14 10:59:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13418 for ; Tue, 14 Oct 2003 10:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qdg-0003HK-Vj for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 10:59:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EEx8l6012602 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 10:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qdg-0003HB-Qy for simple-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 10:59:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13389; Tue, 14 Oct 2003 10:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qdd-0003lo-00; Tue, 14 Oct 2003 10:59:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Qdd-0003ll-00; Tue, 14 Oct 2003 10:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QdZ-0003EQ-JQ; Tue, 14 Oct 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qcl-0003DQ-68 for simple@optimus.ietf.org; Tue, 14 Oct 2003 10:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13370 for ; Tue, 14 Oct 2003 10:58:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qci-0003kw-00 for simple@ietf.org; Tue, 14 Oct 2003 10:58:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Qci-0003kU-00 for simple@ietf.org; Tue, 14 Oct 2003 10:58:08 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2003 08:07:05 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9EEvYeH023985; Tue, 14 Oct 2003 07:57:34 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC93546; Tue, 14 Oct 2003 10:57:33 -0400 (EDT) Message-ID: <3F8C0EDD.2070509@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Ben Campbell , Hisham Khartabil , cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> <3F8B1699.4030104@cisco.com> <1066086684.937.60.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 10:57:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I thought that Ben's timeout approach didn't work, but after looking at it more closely I have convinced myself that it does work after all. Here is my analysis: With a single relay R, states of a given message are roughly: 1) message in transit from UAC to R 2) message being processed by R 3) message in transit from R to UAS 4) message being processed by UAS 5) response in transit from UAS to R 6) response being processed by R 7) response in transit from R to UAC A UAC that sends a request only knows it is in one of those states, not which one. If the link to the UAC fails while a request is outstanding, the UAC will need to retransmit it on a new connection to ensure it gets through. That will be no problem if the message is in states 1-3, but it will result in message duplication if the message was in states 4-7. The trick is to ensure no messages are in states 4-7. Ben proposed a shutdown strategy where R begins returning an error response for each message arriving at R, while continuing to relay previously received messages and both previously and newly arrived responses. Then, after a waiting period of time TW in this mode, it simply drops all of its connections. Using this strategy, if the times for each state are bounded (T1...T7), and TW > (T2 + ... + T7), then any remaining messages will be in state 1. R can't do anything to prevent messages being in state 1, but it doesn't matter because when the UAC detects the error from shutdown, its recovery action of retransmitting them will be correct and will not result in duplication. This supposes that the durations of the different states are reasonably bounded. This assumtion may be violated for large messages. But perhaps they aren't really a problem. For a large message, if R has not yet transmitted all of it on to UAS, it can simply cease transmitting more of it, and send an error response back to the UAC. The UAS will eventually realize there is an error when the connection to R goes down. As long as it doesn't present the partial message things will be ok. This leaves a case where the message is large and all of it has been transmitted by R. If the latency between R sending the last byte of the message and receiving the response is not reasonably bounded then there is still a problem. This doesn't seem like a likely case. Large responses would also screw things up, but I think we have defined things so that this is never the case. The two relay case is more complex, but it feels like the results will be the same. If nobody can shoot any holes in the above, I am prepared to agree with you that choice 1 is acceptable for relay shutdown, so that choices 2 & 3 have no particular advantage over it. There could still be value to choice 4. It would eliminate any need for waiting and sending errors during shutdown of a relay. In addition, it would also work for failover when a relay crashes. But I'm not sure I want this discussion to go there right now. Paul Robert Sparks wrote: > (as non-chair). > > I think the edge conditions we are talking about here are sufficiently > edge that we should document them and not take on the burden of trying > to prevent them. > > I prefer option 1. > > RjS > > > On Mon, 2003-10-13 at 16:18, Paul Kyzivat wrote: > >>Ben Campbell wrote: >> >>>I did not say it was good. I said I think we can live with it. That is >>>not the same thing. >>> >>>It seems to me we have 4 choices: >>> >>>1) Live with the potential for duplicate deliveries when a logical >>>conversation transitions from one session to another in a short time >>>period. Note that this can happen without relays being involved at all. >>> >>>2) Require any hosting device that wishes to end a session wait either >>>until connected devices send a request, so that we can send a response >>>indicating that we are shutting down, or until an inactivity timeout >>>occurs. >>> >>>3) Allow relays to originate a message saying the session is going down. >>> >>>4) Create a cross-session duplicate supression mechanism. >>> >>>3) and 4) seem awfully heavy-weight for the value they create. 2) either >>>puts a big burden on hosting device shutdown time, or requires us to >>>significantly shorten the timer value--which, as has been discussed at >>>length on this list, is also heavy-weight. >>> >>>Of these choices, I prefer option 1. >> >>I think you managed to summarize the choices quite well. >> >>I prefer either 2, or 4. Of those, 2 is the simpler, and I would be ok >>with reducing the timer value to make it responsive enough. OTOH, 4 also >>works in the case of a server crashing ungracefully, which 2 won't cover. >> >>I think 1 is a non-starter. We are all geeks, and can be tolerant of >>such misbehavior if we understand why it is happening. Others will not >>be so tolerant. They especially won't be tolerant if the message happens >>to be their 5gb movie. >> >>Now that I think about it, the 5gb message may be a reason to prefer 4. >>(Or 3): I don't think 2 works for that case. >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 14 11:39:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15262; Tue, 14 Oct 2003 11:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RGS-0004HB-00; Tue, 14 Oct 2003 11:39:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9RGR-0004H8-00; Tue, 14 Oct 2003 11:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RGG-0006H3-UU; Tue, 14 Oct 2003 11:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RFZ-0006CN-Jg for simple@optimus.ietf.org; Tue, 14 Oct 2003 11:38:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15219 for ; Tue, 14 Oct 2003 11:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RFY-0004GM-00 for simple@ietf.org; Tue, 14 Oct 2003 11:38:16 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A9RFX-0004GE-00 for simple@ietf.org; Tue, 14 Oct 2003 11:38:15 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9EFbseY033613; Tue, 14 Oct 2003 10:38:00 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8C184C.30303@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Robert Sparks , Hisham Khartabil , cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> <3F8B1699.4030104@cisco.com> <1066086684.937.60.camel@RjS.localdomain> <3F8C0EDD.2070509@cisco.com> In-Reply-To: <3F8C0EDD.2070509@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 10:37:48 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I thought that Ben's timeout approach didn't work, but after looking at > it more closely I have convinced myself that it does work after all. > Here is my analysis: > > With a single relay R, states of a given message are roughly: > > 1) message in transit from UAC to R > 2) message being processed by R > 3) message in transit from R to UAS > 4) message being processed by UAS > 5) response in transit from UAS to R > 6) response being processed by R > 7) response in transit from R to UAC > > A UAC that sends a request only knows it is in one of those states, not > which one. If the link to the UAC fails while a request is outstanding, > the UAC will need to retransmit it on a new connection to ensure it gets > through. That will be no problem if the message is in states 1-3, but it > will result in message duplication if the message was in states 4-7. The > trick is to ensure no messages are in states 4-7. Ah, you have just convinced me that the one problem I was worried about (i.e. state 1) is not really a problem. That is, requests that end in state 1 are known to have not been delivered, and resending them will not result in a duplicate. So I think that, rather than characterizing this approach as a partial solution, we can consider it a complete solution, pending correct selection of Tw. > > Ben proposed a shutdown strategy where R begins returning an error > response for each message arriving at R, while continuing to relay > previously received messages and both previously and newly arrived > responses. Then, after a waiting period of time TW in this mode, it > simply drops all of its connections. > > Using this strategy, if the times for each state are bounded (T1...T7), > and TW > (T2 + ... + T7), then any remaining messages will be in state > 1. R can't do anything to prevent messages being in state 1, but it > doesn't matter because when the UAC detects the error from shutdown, its > recovery action of retransmitting them will be correct and will not > result in duplication. > > This supposes that the durations of the different states are reasonably > bounded. This assumtion may be violated for large messages. But perhaps > they aren't really a problem. For a large message, if R has not yet > transmitted all of it on to UAS, it can simply cease transmitting more > of it, and send an error response back to the UAC. The UAS will > eventually realize there is an error when the connection to R goes down. > As long as it doesn't present the partial message things will be ok. > > This leaves a case where the message is large and all of it has been > transmitted by R. If the latency between R sending the last byte of the > message and receiving the response is not reasonably bounded then there > is still a problem. This doesn't seem like a likely case. Yes. This brings us back to the concept of MSRP transaction timeouts. The draft currently says the sender should wait some "reasonable" period of time after sending the last byte of the message giving up on the transaction. A "reasonable" time should take the latencies you mention into account (perehaps for 2 relays.) Previously, it was not important that all devices have the same definition of "reasonable". But it seems like the period the relay should wait before closing connections is the same as the period a client should wait before giving up on a transaction. So for this approach to work well, we may need to actually standardise that value. > > Large responses would also screw things up, but I think we have defined > things so that this is never the case. I certainly hope so. > > The two relay case is more complex, but it feels like the results will > be the same. I think the 2 relay case adds more states, and possibly indicates a larger value for Tw. But if you define state 1 for any relay as meaning the request is somewhere between the client and the relay (possibly being processed by another intervening relay.), the model still holds up. > > If nobody can shoot any holes in the above, I am prepared to agree with > you that choice 1 is acceptable for relay shutdown, so that choices 2 & > 3 have no particular advantage over it. > > There could still be value to choice 4. It would eliminate any need for > waiting and sending errors during shutdown of a relay. In addition, it > would also work for failover when a relay crashes. But I'm not sure I > want this discussion to go there right now. > > Paul > [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 14 11:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15288 for ; Tue, 14 Oct 2003 11:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RGT-0006J5-T7 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 11:39:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EFdDPQ024237 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 11:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RGT-0006Iq-Oq for simple-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 11:39:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15262; Tue, 14 Oct 2003 11:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RGS-0004HB-00; Tue, 14 Oct 2003 11:39:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9RGR-0004H8-00; Tue, 14 Oct 2003 11:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RGG-0006H3-UU; Tue, 14 Oct 2003 11:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RFZ-0006CN-Jg for simple@optimus.ietf.org; Tue, 14 Oct 2003 11:38:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15219 for ; Tue, 14 Oct 2003 11:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RFY-0004GM-00 for simple@ietf.org; Tue, 14 Oct 2003 11:38:16 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A9RFX-0004GE-00 for simple@ietf.org; Tue, 14 Oct 2003 11:38:15 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9EFbseY033613; Tue, 14 Oct 2003 10:38:00 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8C184C.30303@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Robert Sparks , Hisham Khartabil , cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB70179723B@esebe019.ntc.nokia.com> <3F8AEE16.4060206@dynamicsoft.com> <3F8AF68A.5050700@cisco.com> <3F8B0949.3060204@dynamicsoft.com> <3F8B1699.4030104@cisco.com> <1066086684.937.60.camel@RjS.localdomain> <3F8C0EDD.2070509@cisco.com> In-Reply-To: <3F8C0EDD.2070509@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 10:37:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I thought that Ben's timeout approach didn't work, but after looking at > it more closely I have convinced myself that it does work after all. > Here is my analysis: > > With a single relay R, states of a given message are roughly: > > 1) message in transit from UAC to R > 2) message being processed by R > 3) message in transit from R to UAS > 4) message being processed by UAS > 5) response in transit from UAS to R > 6) response being processed by R > 7) response in transit from R to UAC > > A UAC that sends a request only knows it is in one of those states, not > which one. If the link to the UAC fails while a request is outstanding, > the UAC will need to retransmit it on a new connection to ensure it gets > through. That will be no problem if the message is in states 1-3, but it > will result in message duplication if the message was in states 4-7. The > trick is to ensure no messages are in states 4-7. Ah, you have just convinced me that the one problem I was worried about (i.e. state 1) is not really a problem. That is, requests that end in state 1 are known to have not been delivered, and resending them will not result in a duplicate. So I think that, rather than characterizing this approach as a partial solution, we can consider it a complete solution, pending correct selection of Tw. > > Ben proposed a shutdown strategy where R begins returning an error > response for each message arriving at R, while continuing to relay > previously received messages and both previously and newly arrived > responses. Then, after a waiting period of time TW in this mode, it > simply drops all of its connections. > > Using this strategy, if the times for each state are bounded (T1...T7), > and TW > (T2 + ... + T7), then any remaining messages will be in state > 1. R can't do anything to prevent messages being in state 1, but it > doesn't matter because when the UAC detects the error from shutdown, its > recovery action of retransmitting them will be correct and will not > result in duplication. > > This supposes that the durations of the different states are reasonably > bounded. This assumtion may be violated for large messages. But perhaps > they aren't really a problem. For a large message, if R has not yet > transmitted all of it on to UAS, it can simply cease transmitting more > of it, and send an error response back to the UAC. The UAS will > eventually realize there is an error when the connection to R goes down. > As long as it doesn't present the partial message things will be ok. > > This leaves a case where the message is large and all of it has been > transmitted by R. If the latency between R sending the last byte of the > message and receiving the response is not reasonably bounded then there > is still a problem. This doesn't seem like a likely case. Yes. This brings us back to the concept of MSRP transaction timeouts. The draft currently says the sender should wait some "reasonable" period of time after sending the last byte of the message giving up on the transaction. A "reasonable" time should take the latencies you mention into account (perehaps for 2 relays.) Previously, it was not important that all devices have the same definition of "reasonable". But it seems like the period the relay should wait before closing connections is the same as the period a client should wait before giving up on a transaction. So for this approach to work well, we may need to actually standardise that value. > > Large responses would also screw things up, but I think we have defined > things so that this is never the case. I certainly hope so. > > The two relay case is more complex, but it feels like the results will > be the same. I think the 2 relay case adds more states, and possibly indicates a larger value for Tw. But if you define state 1 for any relay as meaning the request is somewhere between the client and the relay (possibly being processed by another intervening relay.), the model still holds up. > > If nobody can shoot any holes in the above, I am prepared to agree with > you that choice 1 is acceptable for relay shutdown, so that choices 2 & > 3 have no particular advantage over it. > > There could still be value to choice 4. It would eliminate any need for > waiting and sending errors during shutdown of a relay. In addition, it > would also work for failover when a relay crashes. But I'm not sure I > want this discussion to go there right now. > > Paul > [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 14 14:42:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23388; Tue, 14 Oct 2003 14:42:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9U8O-0006Tb-00; Tue, 14 Oct 2003 14:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9U8N-0006TY-00; Tue, 14 Oct 2003 14:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9U8L-0000lw-4z; Tue, 14 Oct 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9U8B-0000ll-5o for simple@optimus.ietf.org; Tue, 14 Oct 2003 14:42:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23384 for ; Tue, 14 Oct 2003 14:42:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9U88-0006TU-00 for simple@ietf.org; Tue, 14 Oct 2003 14:42:48 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A9U87-0006TD-00 for simple@ietf.org; Tue, 14 Oct 2003 14:42:47 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9EIgGiM015524; Tue, 14 Oct 2003 14:42:16 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4X07V2VN>; Tue, 14 Oct 2003 13:42:16 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86510@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , simple@ietf.org Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrati ve shutdown of relays) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 13:42:13 -0500 > One: Do you believe it is important for the document to discuss > administrative shutdown of relays. Yes. > Two: (answer only if you answer Yes to question One). > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. One. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 14 14:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23412 for ; Tue, 14 Oct 2003 14:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9U8R-0000mz-S1 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 14:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EIh7h9003027 for simple-archive@odin.ietf.org; Tue, 14 Oct 2003 14:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9U8R-0000mk-Ll for simple-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23388; Tue, 14 Oct 2003 14:42:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9U8O-0006Tb-00; Tue, 14 Oct 2003 14:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9U8N-0006TY-00; Tue, 14 Oct 2003 14:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9U8L-0000lw-4z; Tue, 14 Oct 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9U8B-0000ll-5o for simple@optimus.ietf.org; Tue, 14 Oct 2003 14:42:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23384 for ; Tue, 14 Oct 2003 14:42:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9U88-0006TU-00 for simple@ietf.org; Tue, 14 Oct 2003 14:42:48 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A9U87-0006TD-00 for simple@ietf.org; Tue, 14 Oct 2003 14:42:47 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9EIgGiM015524; Tue, 14 Oct 2003 14:42:16 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4X07V2VN>; Tue, 14 Oct 2003 13:42:16 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86510@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , simple@ietf.org Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrati ve shutdown of relays) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 13:42:13 -0500 > One: Do you believe it is important for the document to discuss > administrative shutdown of relays. Yes. > Two: (answer only if you answer Yes to question One). > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. One. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 15 09:49:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29528; Wed, 15 Oct 2003 09:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9m1d-0004VX-00; Wed, 15 Oct 2003 09:49:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9m1c-0004VU-00; Wed, 15 Oct 2003 09:49:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9m1O-0007Tu-2w; Wed, 15 Oct 2003 09:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9m0r-0007T9-L0 for simple@optimus.ietf.org; Wed, 15 Oct 2003 09:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29497 for ; Wed, 15 Oct 2003 09:48:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9m0p-0004Uh-00 for simple@ietf.org; Wed, 15 Oct 2003 09:48:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A9m0o-0004Ue-00 for simple@ietf.org; Wed, 15 Oct 2003 09:48:26 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9FDmFX12030 for ; Wed, 15 Oct 2003 16:48:15 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 16:48:15 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 16:48:15 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 16:48:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOR4lvtwi5l2GFoQ2+HC9mBqjrgPwBN+TQw To: , X-OriginalArrivalTime: 15 Oct 2003 13:48:15.0049 (UTC) FILETIME=[FB483390:01C39322] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Oct 2003 16:48:14 +0300 Content-Transfer-Encoding: quoted-printable Hi, Inline. > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 14 October, 2003 02:31 > To: simple@ietf.org > Subject: [Simple] Chair call for group opinion (was MSRP:=20 > Administrative > shutdown of relays) >=20 >=20 > If you have not been reading the Administrative shutdown of relays > thread, the following provides a summary of the possible paths the > thread has explored: >=20 > In interests of progress _before_ Minnesota, I would like to=20 > get input > from people other than the 3 primary participants in the tread as to > what they believe is important for us to work on. >=20 > So, I am calling an electronic hum. Respond to list or privately to > me if you prefer. The questions called are: >=20 > One: Do you believe it is important for the document to discuss > administrative shutdown of relays. No. And I'm going to have to ask a couple of stupid questions, too. 1) Since duplicate delivery is the reason a relay would need to care = about shutting down gracefully in the first place, what are the reasons = a SEND would time out; who drops it; and why would an MSRP endpoint = retransmit if that happens? 2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) = and then shutting down? I thought this is what we wanted to avoid with MSRP. If a relay also = processes the SEND (i.e., receives it in entirety before forwarding it = along on another connection), this bases a big burden on the relay when = the SEND contains a 5GB movie. Why can't a relay simply peek at the first few bytes of message, see if = it is not a BIND or VISIT, and forward it byte-by-byte over to the = associated TCP connection. If there is trouble upstream, simply mirror = that trouble downstream. This way, there are never messages in-transit over relay(s) (with the = exception of a VISIT, which is always processed by a relay, but can also = be forwarded to another target). If the above simply isn't feasible, then my answer would probably be = yes, but I'd have to think between option 1 and 3.=20 Regards, Aki =20 > Two: (answer only if you answer Yes to question One).=20 > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. >=20 > Please respond to this call no later than Wed 10/15. >=20 > RjS > =20 >=20 >=20 >=20 > -----Forwarded Message----- > > From: Ben Campbell > > > > It seems to me we have 4 choices: > >=20 > > 1) Live with the potential for duplicate deliveries when a logical=20 > > conversation transitions from one session to another in a=20 > short time=20 > > period. Note that this can happen without relays being=20 > involved at all. > This potential can be bounded by shorter than inactivity=20 > timeout delays > (specifically watiting for transactions already in progress to > complete). >=20 > > > > 2) Require any hosting device that wishes to end a session=20 > wait either=20 > > until connected devices send a request, so that we can=20 > send a response=20 > > indicating that we are shutting down, or until an=20 > inactivity timeout occurs. > > > > 3) Allow relays to originate a message saying the session=20 > is going down. > >=20 > > 4) Create a cross-session duplicate supression mechanism. > >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 15 09:49:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29590 for ; Wed, 15 Oct 2003 09:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9m1i-0007V9-2o for simple-archive@odin.ietf.org; Wed, 15 Oct 2003 09:49:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FDnMmv028836 for simple-archive@odin.ietf.org; Wed, 15 Oct 2003 09:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9m1g-0007V1-7j for simple-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 09:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29528; Wed, 15 Oct 2003 09:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9m1d-0004VX-00; Wed, 15 Oct 2003 09:49:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9m1c-0004VU-00; Wed, 15 Oct 2003 09:49:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9m1O-0007Tu-2w; Wed, 15 Oct 2003 09:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9m0r-0007T9-L0 for simple@optimus.ietf.org; Wed, 15 Oct 2003 09:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29497 for ; Wed, 15 Oct 2003 09:48:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9m0p-0004Uh-00 for simple@ietf.org; Wed, 15 Oct 2003 09:48:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A9m0o-0004Ue-00 for simple@ietf.org; Wed, 15 Oct 2003 09:48:26 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9FDmFX12030 for ; Wed, 15 Oct 2003 16:48:15 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 16:48:15 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 16:48:15 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 16:48:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOR4lvtwi5l2GFoQ2+HC9mBqjrgPwBN+TQw To: , X-OriginalArrivalTime: 15 Oct 2003 13:48:15.0049 (UTC) FILETIME=[FB483390:01C39322] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Oct 2003 16:48:14 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Inline. > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 14 October, 2003 02:31 > To: simple@ietf.org > Subject: [Simple] Chair call for group opinion (was MSRP:=20 > Administrative > shutdown of relays) >=20 >=20 > If you have not been reading the Administrative shutdown of relays > thread, the following provides a summary of the possible paths the > thread has explored: >=20 > In interests of progress _before_ Minnesota, I would like to=20 > get input > from people other than the 3 primary participants in the tread as to > what they believe is important for us to work on. >=20 > So, I am calling an electronic hum. Respond to list or privately to > me if you prefer. The questions called are: >=20 > One: Do you believe it is important for the document to discuss > administrative shutdown of relays. No. And I'm going to have to ask a couple of stupid questions, too. 1) Since duplicate delivery is the reason a relay would need to care = about shutting down gracefully in the first place, what are the reasons = a SEND would time out; who drops it; and why would an MSRP endpoint = retransmit if that happens? 2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) = and then shutting down? I thought this is what we wanted to avoid with MSRP. If a relay also = processes the SEND (i.e., receives it in entirety before forwarding it = along on another connection), this bases a big burden on the relay when = the SEND contains a 5GB movie. Why can't a relay simply peek at the first few bytes of message, see if = it is not a BIND or VISIT, and forward it byte-by-byte over to the = associated TCP connection. If there is trouble upstream, simply mirror = that trouble downstream. This way, there are never messages in-transit over relay(s) (with the = exception of a VISIT, which is always processed by a relay, but can also = be forwarded to another target). If the above simply isn't feasible, then my answer would probably be = yes, but I'd have to think between option 1 and 3.=20 Regards, Aki =20 > Two: (answer only if you answer Yes to question One).=20 > How much scope creep are we willing to take on? > The options below are listed in increasing scope creep order. > Please respond with which option you would like to see pursued. >=20 > Please respond to this call no later than Wed 10/15. >=20 > RjS > =20 >=20 >=20 >=20 > -----Forwarded Message----- > > From: Ben Campbell > > > > It seems to me we have 4 choices: > >=20 > > 1) Live with the potential for duplicate deliveries when a logical=20 > > conversation transitions from one session to another in a=20 > short time=20 > > period. Note that this can happen without relays being=20 > involved at all. > This potential can be bounded by shorter than inactivity=20 > timeout delays > (specifically watiting for transactions already in progress to > complete). >=20 > > > > 2) Require any hosting device that wishes to end a session=20 > wait either=20 > > until connected devices send a request, so that we can=20 > send a response=20 > > indicating that we are shutting down, or until an=20 > inactivity timeout occurs. > > > > 3) Allow relays to originate a message saying the session=20 > is going down. > >=20 > > 4) Create a cross-session duplicate supression mechanism. > >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 15 13:43:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12523; Wed, 15 Oct 2003 13:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pfw-0000lI-00; Wed, 15 Oct 2003 13:43:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9pfv-0000lA-00; Wed, 15 Oct 2003 13:43:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pfp-0007EP-Cq; Wed, 15 Oct 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pfG-0007Df-Go for simple@optimus.ietf.org; Wed, 15 Oct 2003 13:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12489 for ; Wed, 15 Oct 2003 13:42:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pfE-0000kr-00 for simple@ietf.org; Wed, 15 Oct 2003 13:42:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9pfD-0000k6-00 for simple@ietf.org; Wed, 15 Oct 2003 13:42:23 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9FHfovA008947; Wed, 15 Oct 2003 10:41:50 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADD98031; Wed, 15 Oct 2003 13:41:48 -0400 (EDT) Message-ID: <3F8D86DC.10007@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Oct 2003 13:41:48 -0400 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > > One: Do you believe it is important for the document to discuss > > administrative shutdown of relays. > > No. And I'm going to have to ask a couple of stupid questions, too. > > 1) Since duplicate delivery is the reason a relay would need to care about shutting down gracefully in the first place, what are the reasons a SEND would time out; who drops it; and why would an MSRP endpoint retransmit if that happens? Lets look at application view first. The application has a message to send to the other end. Its responsibility is to ensure it gets there. It is using an MSRP connection to deliver the message. Meanwhile the operator of the relay needs to shut down relays from time to time. We want to ensure that the shutting down of the relay doesn't prevent the application from ensuring that the messages it sent get to the other end. If the relay is shut down without advance notice of the application, there is certainly a chance that a message sent by the app will not arrive. If the application wants to survive the relay shutdown, then it will need to somehow detect the situation, establish a new connection, and retry the send. Relays shutting down gracefully, and timeouts on messages are simply ways for the application to learn what it needs to achieve its ends. Without some help, the application can't do this. > 2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) and then shutting down? SIP errs on the side of sending duplicates, and depends on the recipient to recognize and discard them. Doing the same in MSRP is the 4th choice in the vote. > I thought this is what we wanted to avoid with MSRP. If a relay also processes the SEND (i.e., receives it in entirety before forwarding it along on another connection), this bases a big burden on the relay when the SEND contains a 5GB movie. A relay clearly does "process" a SEND, but I don't think we have made any require that it receive the whole thing before forwarding it on. If that is what you mean we wanted to avoid, then I think we have. > Why can't a relay simply peek at the first few bytes of message, see if it is not a BIND or VISIT, and forward it byte-by-byte over to the associated TCP connection. If there is trouble upstream, simply mirror that trouble downstream. It can. It can also know that it is in the midst of forwarding a message. If it wants to shutdown before transmitting the last byte of the message, it can send an error response indicating this is what happened. > This way, there are never messages in-transit over relay(s) (with the exception of a VISIT, which is always processed by a relay, but can also be forwarded to another target). I don't see why this means there aren't messages in-transit. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 15 13:43:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12551 for ; Wed, 15 Oct 2003 13:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pfz-0007FG-Q0 for simple-archive@odin.ietf.org; Wed, 15 Oct 2003 13:43:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FHhBUE027847 for simple-archive@odin.ietf.org; Wed, 15 Oct 2003 13:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pfz-0007F4-Mt for simple-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 13:43:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12523; Wed, 15 Oct 2003 13:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pfw-0000lI-00; Wed, 15 Oct 2003 13:43:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9pfv-0000lA-00; Wed, 15 Oct 2003 13:43:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pfp-0007EP-Cq; Wed, 15 Oct 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pfG-0007Df-Go for simple@optimus.ietf.org; Wed, 15 Oct 2003 13:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12489 for ; Wed, 15 Oct 2003 13:42:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pfE-0000kr-00 for simple@ietf.org; Wed, 15 Oct 2003 13:42:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9pfD-0000k6-00 for simple@ietf.org; Wed, 15 Oct 2003 13:42:23 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9FHfovA008947; Wed, 15 Oct 2003 10:41:50 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADD98031; Wed, 15 Oct 2003 13:41:48 -0400 (EDT) Message-ID: <3F8D86DC.10007@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Oct 2003 13:41:48 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > > One: Do you believe it is important for the document to discuss > > administrative shutdown of relays. > > No. And I'm going to have to ask a couple of stupid questions, too. > > 1) Since duplicate delivery is the reason a relay would need to care about shutting down gracefully in the first place, what are the reasons a SEND would time out; who drops it; and why would an MSRP endpoint retransmit if that happens? Lets look at application view first. The application has a message to send to the other end. Its responsibility is to ensure it gets there. It is using an MSRP connection to deliver the message. Meanwhile the operator of the relay needs to shut down relays from time to time. We want to ensure that the shutting down of the relay doesn't prevent the application from ensuring that the messages it sent get to the other end. If the relay is shut down without advance notice of the application, there is certainly a chance that a message sent by the app will not arrive. If the application wants to survive the relay shutdown, then it will need to somehow detect the situation, establish a new connection, and retry the send. Relays shutting down gracefully, and timeouts on messages are simply ways for the application to learn what it needs to achieve its ends. Without some help, the application can't do this. > 2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) and then shutting down? SIP errs on the side of sending duplicates, and depends on the recipient to recognize and discard them. Doing the same in MSRP is the 4th choice in the vote. > I thought this is what we wanted to avoid with MSRP. If a relay also processes the SEND (i.e., receives it in entirety before forwarding it along on another connection), this bases a big burden on the relay when the SEND contains a 5GB movie. A relay clearly does "process" a SEND, but I don't think we have made any require that it receive the whole thing before forwarding it on. If that is what you mean we wanted to avoid, then I think we have. > Why can't a relay simply peek at the first few bytes of message, see if it is not a BIND or VISIT, and forward it byte-by-byte over to the associated TCP connection. If there is trouble upstream, simply mirror that trouble downstream. It can. It can also know that it is in the midst of forwarding a message. If it wants to shutdown before transmitting the last byte of the message, it can send an error response indicating this is what happened. > This way, there are never messages in-transit over relay(s) (with the exception of a VISIT, which is always processed by a relay, but can also be forwarded to another target). I don't see why this means there aren't messages in-transit. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 05:38:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25833; Thu, 16 Oct 2003 05:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA4b3-0002Xt-00; Thu, 16 Oct 2003 05:39:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA4b2-0002Xq-00; Thu, 16 Oct 2003 05:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4az-0003Pg-By; Thu, 16 Oct 2003 05:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4ao-0003PJ-J6 for simple@optimus.ietf.org; Thu, 16 Oct 2003 05:38:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25822 for ; Thu, 16 Oct 2003 05:38:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA4ak-0002Xd-00 for simple@ietf.org; Thu, 16 Oct 2003 05:38:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AA4ak-0002Xa-00 for simple@ietf.org; Thu, 16 Oct 2003 05:38:46 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9G9ckd15732 for ; Thu, 16 Oct 2003 12:38:46 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Oct 2003 12:38:44 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 12:38:43 +0300 Message-ID: <3F8E6723.2020702@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> <3F8D86DC.10007@cisco.com> In-Reply-To: <3F8D86DC.10007@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 09:38:43.0343 (UTC) FILETIME=[49DCE9F0:01C393C9] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 12:38:43 +0300 Content-Transfer-Encoding: 7bit Hi Paul, Thanks for the answers. I also had a closer look at the analysis you sent in another email, and I think I understand the problem a little better, and must agree it exists. But first off, I'd like to better understand what the requirements for relay shutdown are. If there isn't a strict time window, the obvious solution is for a relay to reject all new BINDs and VISITs until it has no active sessions ongoing, and then shut down. If the administrator can't wait that long, then I would treat this more as an error scenario rather than something we need to document in the spec. A relay is supposed to host the session as long as it's active. So my answer would still be no but a few other things still bothering me inline... On 15.10.2003 20:41, ext Paul Kyzivat: > > aki.niemi@nokia.com wrote: >> >>> One: Do you believe it is important for the document to discuss >>> administrative shutdown of relays. >> >> No. And I'm going to have to ask a couple of stupid questions, too. >> >> >> 1) Since duplicate delivery is the reason a relay would need to >> care about shutting down gracefully in the first place, what are >> the reasons a SEND would time out; who drops it; and why would an >> MSRP endpoint retransmit if that happens? > > Lets look at application view first. The application has a message to > send to the other end. Its responsibility is to ensure it gets > there. It is using an MSRP connection to deliver the message. > > Meanwhile the operator of the relay needs to shut down relays from > time to time. > > We want to ensure that the shutting down of the relay doesn't prevent > the application from ensuring that the messages it sent get to the > other end. > > If the relay is shut down without advance notice of the application, > there is certainly a chance that a message sent by the app will not > arrive. If the application wants to survive the relay shutdown, then > it will need to somehow detect the situation, establish a new > connection, and retry the send. IMO, this behavior is not specified in the spec. Request timeouts are interpreted as 5xx, which means the client will resend a few times and then give up. We need text describing how and when an MSRP session transitions to a new connection (or alternatively, someone can point me to the existing text ;)) > Relays shutting down gracefully, and timeouts on messages are simply > ways for the application to learn what it needs to achieve its ends. > Without some help, the application can't do this. Naturally, some help is also provided by the reliable connection the MSRP runs on top of. >> 2) Isn't this identical to a proxy server forwarding a MESSAGE (via >> TCP) and then shutting down? > > SIP errs on the side of sending duplicates, and depends on the > recipient to recognize and discard them. Doing the same in MSRP is > the 4th choice in the vote. Right. I guess the difference in MSRP is that a TR-ID is only unique within a connection. Does it need to be? Could option#4 simply be to make TR-ID globally unique? >> I thought this is what we wanted to avoid with MSRP. If a relay >> also processes the SEND (i.e., receives it in entirety before >> forwarding it along on another connection), this bases a big burden >> on the relay when the SEND contains a 5GB movie. > > A relay clearly does "process" a SEND, but I don't think we have made > any require that it receive the whole thing before forwarding it on. > If that is what you mean we wanted to avoid, then I think we have. > >> Why can't a relay simply peek at the first few bytes of message, >> see if it is not a BIND or VISIT, and forward it byte-by-byte over >> to the associated TCP connection. If there is trouble upstream, >> simply mirror that trouble downstream. > > It can. It can also know that it is in the midst of forwarding a > message. If it wants to shutdown before transmitting the last byte of > the message, it can send an error response indicating this is what > happened. Except that an MSRP client probably isn't expecting a response to a request it is still in the process of sending? >> This way, there are never messages in-transit over relay(s) (with >> the exception of a VISIT, which is always processed by a relay, but >> can also be forwarded to another target). > > I don't see why this means there aren't messages in-transit. You're right. The problem does not go away. Even though there might be fewer states the system could be in, the relay could still shut down when the request is pending - and the problem would remain. Basically, the reason I'm raising these questions is that at least for the non-relay case, I would like things to be as simple as in IRC. That is, to send a message, you write it to a buffer and flush it. Granted, the presence of relays will make things a bit more complicated, but still we should avoid adding complexity unless it's absolutely necessary. Regards, Aki > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 05:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25850 for ; Thu, 16 Oct 2003 05:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4b8-0003QY-B0 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 05:39:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G9dAsM013175 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 05:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4b8-0003QQ-2z for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 05:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25833; Thu, 16 Oct 2003 05:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA4b3-0002Xt-00; Thu, 16 Oct 2003 05:39:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA4b2-0002Xq-00; Thu, 16 Oct 2003 05:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4az-0003Pg-By; Thu, 16 Oct 2003 05:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA4ao-0003PJ-J6 for simple@optimus.ietf.org; Thu, 16 Oct 2003 05:38:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25822 for ; Thu, 16 Oct 2003 05:38:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA4ak-0002Xd-00 for simple@ietf.org; Thu, 16 Oct 2003 05:38:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AA4ak-0002Xa-00 for simple@ietf.org; Thu, 16 Oct 2003 05:38:46 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9G9ckd15732 for ; Thu, 16 Oct 2003 12:38:46 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Oct 2003 12:38:44 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 12:38:43 +0300 Message-ID: <3F8E6723.2020702@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> <3F8D86DC.10007@cisco.com> In-Reply-To: <3F8D86DC.10007@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 09:38:43.0343 (UTC) FILETIME=[49DCE9F0:01C393C9] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 12:38:43 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Paul, Thanks for the answers. I also had a closer look at the analysis you sent in another email, and I think I understand the problem a little better, and must agree it exists. But first off, I'd like to better understand what the requirements for relay shutdown are. If there isn't a strict time window, the obvious solution is for a relay to reject all new BINDs and VISITs until it has no active sessions ongoing, and then shut down. If the administrator can't wait that long, then I would treat this more as an error scenario rather than something we need to document in the spec. A relay is supposed to host the session as long as it's active. So my answer would still be no but a few other things still bothering me inline... On 15.10.2003 20:41, ext Paul Kyzivat: > > aki.niemi@nokia.com wrote: >> >>> One: Do you believe it is important for the document to discuss >>> administrative shutdown of relays. >> >> No. And I'm going to have to ask a couple of stupid questions, too. >> >> >> 1) Since duplicate delivery is the reason a relay would need to >> care about shutting down gracefully in the first place, what are >> the reasons a SEND would time out; who drops it; and why would an >> MSRP endpoint retransmit if that happens? > > Lets look at application view first. The application has a message to > send to the other end. Its responsibility is to ensure it gets > there. It is using an MSRP connection to deliver the message. > > Meanwhile the operator of the relay needs to shut down relays from > time to time. > > We want to ensure that the shutting down of the relay doesn't prevent > the application from ensuring that the messages it sent get to the > other end. > > If the relay is shut down without advance notice of the application, > there is certainly a chance that a message sent by the app will not > arrive. If the application wants to survive the relay shutdown, then > it will need to somehow detect the situation, establish a new > connection, and retry the send. IMO, this behavior is not specified in the spec. Request timeouts are interpreted as 5xx, which means the client will resend a few times and then give up. We need text describing how and when an MSRP session transitions to a new connection (or alternatively, someone can point me to the existing text ;)) > Relays shutting down gracefully, and timeouts on messages are simply > ways for the application to learn what it needs to achieve its ends. > Without some help, the application can't do this. Naturally, some help is also provided by the reliable connection the MSRP runs on top of. >> 2) Isn't this identical to a proxy server forwarding a MESSAGE (via >> TCP) and then shutting down? > > SIP errs on the side of sending duplicates, and depends on the > recipient to recognize and discard them. Doing the same in MSRP is > the 4th choice in the vote. Right. I guess the difference in MSRP is that a TR-ID is only unique within a connection. Does it need to be? Could option#4 simply be to make TR-ID globally unique? >> I thought this is what we wanted to avoid with MSRP. If a relay >> also processes the SEND (i.e., receives it in entirety before >> forwarding it along on another connection), this bases a big burden >> on the relay when the SEND contains a 5GB movie. > > A relay clearly does "process" a SEND, but I don't think we have made > any require that it receive the whole thing before forwarding it on. > If that is what you mean we wanted to avoid, then I think we have. > >> Why can't a relay simply peek at the first few bytes of message, >> see if it is not a BIND or VISIT, and forward it byte-by-byte over >> to the associated TCP connection. If there is trouble upstream, >> simply mirror that trouble downstream. > > It can. It can also know that it is in the midst of forwarding a > message. If it wants to shutdown before transmitting the last byte of > the message, it can send an error response indicating this is what > happened. Except that an MSRP client probably isn't expecting a response to a request it is still in the process of sending? >> This way, there are never messages in-transit over relay(s) (with >> the exception of a VISIT, which is always processed by a relay, but >> can also be forwarded to another target). > > I don't see why this means there aren't messages in-transit. You're right. The problem does not go away. Even though there might be fewer states the system could be in, the relay could still shut down when the request is pending - and the problem would remain. Basically, the reason I'm raising these questions is that at least for the non-relay case, I would like things to be as simple as in IRC. That is, to send a message, you write it to a buffer and flush it. Granted, the presence of relays will make things a bit more complicated, but still we should avoid adding complexity unless it's absolutely necessary. Regards, Aki > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 06:10:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26698; Thu, 16 Oct 2003 06:10:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA558-0002rh-00; Thu, 16 Oct 2003 06:10:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA558-0002re-00; Thu, 16 Oct 2003 06:10:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA552-0004ef-Ra; Thu, 16 Oct 2003 06:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA54f-0004dp-DG for simple@optimus.ietf.org; Thu, 16 Oct 2003 06:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26671 for ; Thu, 16 Oct 2003 06:09:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA54a-0002r2-00 for simple@ietf.org; Thu, 16 Oct 2003 06:09:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AA54Z-0002qp-00 for simple@ietf.org; Thu, 16 Oct 2003 06:09:36 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GA9ZX27848 for ; Thu, 16 Oct 2003 13:09:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Oct 2003 13:09:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 13:09:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797293@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcORz+S8qiwRIvQTQQ2knH/iGekWLgB+4jTQ To: , Cc: , X-OriginalArrivalTime: 16 Oct 2003 10:09:35.0007 (UTC) FILETIME=[998A6AF0:01C393CD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 13:09:34 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, October 14, 2003 12:18 AM > To: Ben Campbell > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > > I did not say it was good. I said I think we can live with=20 > it. That is=20 > > not the same thing. > >=20 > > It seems to me we have 4 choices: > >=20 > > 1) Live with the potential for duplicate deliveries when a logical=20 > > conversation transitions from one session to another in a=20 > short time=20 > > period. Note that this can happen without relays being=20 > involved at all. > >=20 > > 2) Require any hosting device that wishes to end a session=20 > wait either=20 > > until connected devices send a request, so that we can send=20 > a response=20 > > indicating that we are shutting down, or until an=20 > inactivity timeout=20 > > occurs. > >=20 > > 3) Allow relays to originate a message saying the session=20 > is going down. > >=20 > > 4) Create a cross-session duplicate supression mechanism. > >=20 > > 3) and 4) seem awfully heavy-weight for the value they=20 > create. 2) either=20 > > puts a big burden on hosting device shutdown time, or=20 > requires us to=20 > > significantly shorten the timer value--which, as has been=20 > discussed at=20 > > length on this list, is also heavy-weight. > >=20 > > Of these choices, I prefer option 1. >=20 > I think you managed to summarize the choices quite well. >=20 > I prefer either 2, or 4. Of those, 2 is the simpler, and I=20 > would be ok=20 > with reducing the timer value to make it responsive enough.=20 > OTOH, 4 also=20 > works in the case of a server crashing ungracefully, which 2=20 > won't cover. >=20 > I think 1 is a non-starter. We are all geeks, and can be tolerant of=20 > such misbehavior if we understand why it is happening. Others=20 > will not=20 > be so tolerant. They especially won't be tolerant if the=20 > message happens=20 > to be their 5gb movie. >=20 > Now that I think about it, the 5gb message may be a reason to=20 > prefer 4.=20 > (Or 3): I don't think 2 works for that case. Is the relay required to receive the whole message before it can respond = to it with a 5xx error response? To ask the same question froma client = point of view: is the client expecting to send the whole message out = before it receives a response? If the answer to both is no, then option = 2 may still work. The problem remains that the relay has started forwarding the message, = but it is being shutdown midway. In this case, we can either mandate the = the relay must not be sutdown unless it has finished what it started, or = the receiving end needs to tolerate receing the first part of a message = again. Regards, Hisham >=20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 06:10:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26742 for ; Thu, 16 Oct 2003 06:10:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA55E-0004g6-78 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 06:10:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GAAGSV017981 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 06:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA55D-0004fw-Uz for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 06:10:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26698; Thu, 16 Oct 2003 06:10:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA558-0002rh-00; Thu, 16 Oct 2003 06:10:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA558-0002re-00; Thu, 16 Oct 2003 06:10:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA552-0004ef-Ra; Thu, 16 Oct 2003 06:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA54f-0004dp-DG for simple@optimus.ietf.org; Thu, 16 Oct 2003 06:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26671 for ; Thu, 16 Oct 2003 06:09:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA54a-0002r2-00 for simple@ietf.org; Thu, 16 Oct 2003 06:09:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AA54Z-0002qp-00 for simple@ietf.org; Thu, 16 Oct 2003 06:09:36 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GA9ZX27848 for ; Thu, 16 Oct 2003 13:09:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Oct 2003 13:09:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 13:09:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797293@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcORz+S8qiwRIvQTQQ2knH/iGekWLgB+4jTQ To: , Cc: , X-OriginalArrivalTime: 16 Oct 2003 10:09:35.0007 (UTC) FILETIME=[998A6AF0:01C393CD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 13:09:34 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, October 14, 2003 12:18 AM > To: Ben Campbell > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] MSRP: Administrative shutdown of relays >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > > I did not say it was good. I said I think we can live with=20 > it. That is=20 > > not the same thing. > >=20 > > It seems to me we have 4 choices: > >=20 > > 1) Live with the potential for duplicate deliveries when a logical=20 > > conversation transitions from one session to another in a=20 > short time=20 > > period. Note that this can happen without relays being=20 > involved at all. > >=20 > > 2) Require any hosting device that wishes to end a session=20 > wait either=20 > > until connected devices send a request, so that we can send=20 > a response=20 > > indicating that we are shutting down, or until an=20 > inactivity timeout=20 > > occurs. > >=20 > > 3) Allow relays to originate a message saying the session=20 > is going down. > >=20 > > 4) Create a cross-session duplicate supression mechanism. > >=20 > > 3) and 4) seem awfully heavy-weight for the value they=20 > create. 2) either=20 > > puts a big burden on hosting device shutdown time, or=20 > requires us to=20 > > significantly shorten the timer value--which, as has been=20 > discussed at=20 > > length on this list, is also heavy-weight. > >=20 > > Of these choices, I prefer option 1. >=20 > I think you managed to summarize the choices quite well. >=20 > I prefer either 2, or 4. Of those, 2 is the simpler, and I=20 > would be ok=20 > with reducing the timer value to make it responsive enough.=20 > OTOH, 4 also=20 > works in the case of a server crashing ungracefully, which 2=20 > won't cover. >=20 > I think 1 is a non-starter. We are all geeks, and can be tolerant of=20 > such misbehavior if we understand why it is happening. Others=20 > will not=20 > be so tolerant. They especially won't be tolerant if the=20 > message happens=20 > to be their 5gb movie. >=20 > Now that I think about it, the 5gb message may be a reason to=20 > prefer 4.=20 > (Or 3): I don't think 2 works for that case. Is the relay required to receive the whole message before it can respond = to it with a 5xx error response? To ask the same question froma client = point of view: is the client expecting to send the whole message out = before it receives a response? If the answer to both is no, then option = 2 may still work. The problem remains that the relay has started forwarding the message, = but it is being shutdown midway. In this case, we can either mandate the = the relay must not be sutdown unless it has finished what it started, or = the receiving end needs to tolerate receing the first part of a message = again. Regards, Hisham >=20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 06:43:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27696; Thu, 16 Oct 2003 06:43:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA5by-0003Bj-00; Thu, 16 Oct 2003 06:44:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA5bx-0003Bg-00; Thu, 16 Oct 2003 06:44:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5bt-0006R2-9l; Thu, 16 Oct 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5b0-0006Pu-Db for simple@optimus.ietf.org; Thu, 16 Oct 2003 06:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27649 for ; Thu, 16 Oct 2003 06:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA5aw-0003AP-00 for simple@ietf.org; Thu, 16 Oct 2003 06:43:02 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AA5av-0003AM-00 for simple@ietf.org; Thu, 16 Oct 2003 06:43:01 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 16 Oct 2003 11:45:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE0219B0E5@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcORz+S8qiwRIvQTQQ2knH/iGekWLgB+4jTQAADzb2A= From: "Chris Boulton" To: , , Cc: Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 11:43:09 +0100 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 16 October 2003 11:10 >To: pkyzivat@cisco.com; bcampbell@dynamicsoft.com >Cc: Chris Boulton; simple@ietf.org >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >> -----Original Message----- >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, October 14, 2003 12:18 AM >> To: Ben Campbell >> Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >> simple@ietf.org >> Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >> >> >> Ben Campbell wrote: >> > >> > I did not say it was good. I said I think we can live with >> it. That is >> > not the same thing. >> > >> > It seems to me we have 4 choices: >> > >> > 1) Live with the potential for duplicate deliveries when a logical >> > conversation transitions from one session to another in a >> short time >> > period. Note that this can happen without relays being >> involved at all. >> > >> > 2) Require any hosting device that wishes to end a session >> wait either >> > until connected devices send a request, so that we can send >> a response >> > indicating that we are shutting down, or until an >> inactivity timeout >> > occurs. >> > >> > 3) Allow relays to originate a message saying the session >> is going down. >> > >> > 4) Create a cross-session duplicate supression mechanism. >> > >> > 3) and 4) seem awfully heavy-weight for the value they >> create. 2) either >> > puts a big burden on hosting device shutdown time, or >> requires us to >> > significantly shorten the timer value--which, as has been >> discussed at >> > length on this list, is also heavy-weight. >> > >> > Of these choices, I prefer option 1. >> >> I think you managed to summarize the choices quite well. >> >> I prefer either 2, or 4. Of those, 2 is the simpler, and I >> would be ok >> with reducing the timer value to make it responsive enough. >> OTOH, 4 also >> works in the case of a server crashing ungracefully, which 2 >> won't cover. >> >> I think 1 is a non-starter. We are all geeks, and can be tolerant of >> such misbehavior if we understand why it is happening. Others >> will not >> be so tolerant. They especially won't be tolerant if the >> message happens >> to be their 5gb movie. >> >> Now that I think about it, the 5gb message may be a reason to >> prefer 4. >> (Or 3): I don't think 2 works for that case. > > >Is the relay required to receive the whole message before it can respond to >it with a 5xx error response? To ask the same question froma client point >of view: is the client expecting to send the whole message out before it >receives a response? If the answer to both is no, then option 2 may still >work. > >The problem remains that the relay has started forwarding the message, but >it is being shutdown midway. In this case, we can either mandate the the >relay must not be sutdown unless it has finished what it started, or the >receiving end needs to tolerate receing the first part of a message again. > >Regards, >Hisham [Chris Boulton] As this is an administrative shutdown, should we not just wait until the current message has been forwarded (but include a generous timeout for ridiculous size transfer). If this timeout is then exceeded, you just dump the connections and the client has to resend using an alternative TR-ID. =20 > >> Paul >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 06:44:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27744 for ; Thu, 16 Oct 2003 06:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5c3-0006Su-Os for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 06:44:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GAiBhw024846 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 06:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5c3-0006Sf-Ky for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 06:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27696; Thu, 16 Oct 2003 06:43:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA5by-0003Bj-00; Thu, 16 Oct 2003 06:44:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA5bx-0003Bg-00; Thu, 16 Oct 2003 06:44:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5bt-0006R2-9l; Thu, 16 Oct 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA5b0-0006Pu-Db for simple@optimus.ietf.org; Thu, 16 Oct 2003 06:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27649 for ; Thu, 16 Oct 2003 06:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA5aw-0003AP-00 for simple@ietf.org; Thu, 16 Oct 2003 06:43:02 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AA5av-0003AM-00 for simple@ietf.org; Thu, 16 Oct 2003 06:43:01 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 16 Oct 2003 11:45:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Administrative shutdown of relays Message-ID: <45730E094814E44488F789C1CDED27AE0219B0E5@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Administrative shutdown of relays Thread-Index: AcORz+S8qiwRIvQTQQ2knH/iGekWLgB+4jTQAADzb2A= From: "Chris Boulton" To: , , Cc: Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 11:43:09 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 16 October 2003 11:10 >To: pkyzivat@cisco.com; bcampbell@dynamicsoft.com >Cc: Chris Boulton; simple@ietf.org >Subject: RE: [Simple] MSRP: Administrative shutdown of relays > > > >> -----Original Message----- >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, October 14, 2003 12:18 AM >> To: Ben Campbell >> Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >> simple@ietf.org >> Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >> >> >> Ben Campbell wrote: >> > >> > I did not say it was good. I said I think we can live with >> it. That is >> > not the same thing. >> > >> > It seems to me we have 4 choices: >> > >> > 1) Live with the potential for duplicate deliveries when a logical >> > conversation transitions from one session to another in a >> short time >> > period. Note that this can happen without relays being >> involved at all. >> > >> > 2) Require any hosting device that wishes to end a session >> wait either >> > until connected devices send a request, so that we can send >> a response >> > indicating that we are shutting down, or until an >> inactivity timeout >> > occurs. >> > >> > 3) Allow relays to originate a message saying the session >> is going down. >> > >> > 4) Create a cross-session duplicate supression mechanism. >> > >> > 3) and 4) seem awfully heavy-weight for the value they >> create. 2) either >> > puts a big burden on hosting device shutdown time, or >> requires us to >> > significantly shorten the timer value--which, as has been >> discussed at >> > length on this list, is also heavy-weight. >> > >> > Of these choices, I prefer option 1. >> >> I think you managed to summarize the choices quite well. >> >> I prefer either 2, or 4. Of those, 2 is the simpler, and I >> would be ok >> with reducing the timer value to make it responsive enough. >> OTOH, 4 also >> works in the case of a server crashing ungracefully, which 2 >> won't cover. >> >> I think 1 is a non-starter. We are all geeks, and can be tolerant of >> such misbehavior if we understand why it is happening. Others >> will not >> be so tolerant. They especially won't be tolerant if the >> message happens >> to be their 5gb movie. >> >> Now that I think about it, the 5gb message may be a reason to >> prefer 4. >> (Or 3): I don't think 2 works for that case. > > >Is the relay required to receive the whole message before it can respond to >it with a 5xx error response? To ask the same question froma client point >of view: is the client expecting to send the whole message out before it >receives a response? If the answer to both is no, then option 2 may still >work. > >The problem remains that the relay has started forwarding the message, but >it is being shutdown midway. In this case, we can either mandate the the >relay must not be sutdown unless it has finished what it started, or the >receiving end needs to tolerate receing the first part of a message again. > >Regards, >Hisham [Chris Boulton] As this is an administrative shutdown, should we not just wait until the current message has been forwarded (but include a generous timeout for ridiculous size transfer). If this timeout is then exceeded, you just dump the connections and the client has to resend using an alternative TR-ID. =20 > >> Paul >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 10:41:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05646; Thu, 16 Oct 2003 10:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA9KE-0005WH-00; Thu, 16 Oct 2003 10:42:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA9KD-0005WE-00; Thu, 16 Oct 2003 10:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9KE-0005mW-CC; Thu, 16 Oct 2003 10:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9K6-0005ll-5i for simple@optimus.ietf.org; Thu, 16 Oct 2003 10:41:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05639 for ; Thu, 16 Oct 2003 10:41:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA9K3-0005Vz-00 for simple@ietf.org; Thu, 16 Oct 2003 10:41:51 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AA9K2-0005Vw-00 for simple@ietf.org; Thu, 16 Oct 2003 10:41:51 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9GEfieY060674; Thu, 16 Oct 2003 09:41:44 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8EAE1E.5000004@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB701797293@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797293@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 09:41:34 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, October 14, 2003 12:18 AM >>To: Ben Campbell >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >>simple@ietf.org >>Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >> >> >>Ben Campbell wrote: >> >>>I did not say it was good. I said I think we can live with >> >>it. That is >> >>>not the same thing. >>> >>>It seems to me we have 4 choices: >>> >>>1) Live with the potential for duplicate deliveries when a logical >>>conversation transitions from one session to another in a >> >>short time >> >>>period. Note that this can happen without relays being >> >>involved at all. >> >>>2) Require any hosting device that wishes to end a session >> >>wait either >> >>>until connected devices send a request, so that we can send >> >>a response >> >>>indicating that we are shutting down, or until an >> >>inactivity timeout >> >>>occurs. >>> >>>3) Allow relays to originate a message saying the session >> >>is going down. >> >>>4) Create a cross-session duplicate supression mechanism. >>> >>>3) and 4) seem awfully heavy-weight for the value they >> >>create. 2) either >> >>>puts a big burden on hosting device shutdown time, or >> >>requires us to >> >>>significantly shorten the timer value--which, as has been >> >>discussed at >> >>>length on this list, is also heavy-weight. >>> >>>Of these choices, I prefer option 1. >> >>I think you managed to summarize the choices quite well. >> >>I prefer either 2, or 4. Of those, 2 is the simpler, and I >>would be ok >>with reducing the timer value to make it responsive enough. >>OTOH, 4 also >>works in the case of a server crashing ungracefully, which 2 >>won't cover. >> >>I think 1 is a non-starter. We are all geeks, and can be tolerant of >>such misbehavior if we understand why it is happening. Others >>will not >>be so tolerant. They especially won't be tolerant if the >>message happens >>to be their 5gb movie. >> >>Now that I think about it, the 5gb message may be a reason to >>prefer 4. >>(Or 3): I don't think 2 works for that case. > > > > Is the relay required to receive the whole message before it can respond to it with a 5xx error response? To ask the same question froma client point of view: is the client expecting to send the whole message out before it receives a response? If the answer to both is no, then option 2 may still work. No, it is not. We already allow devices to interrupt a long message by sending an early response. That device must, however, also drop the connection, as framing is pretty much done for at this point. But given that Paul has agreed that option 1 does not introduce duplicate messages, why are we still considering option 2? Do you disagree with Paul's analysis? > > The problem remains that the relay has started forwarding the message, but it is being shutdown midway. In this case, we can either mandate the the relay must not be sutdown unless it has finished what it started, or the receiving end needs to tolerate receing the first part of a message again. > That is already implied by the ability to interrupt messages. > Regards, > Hisham > > >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 10:42:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05691 for ; Thu, 16 Oct 2003 10:42:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9KH-0005oe-EB for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 10:42:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GEg5rv022349 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 10:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9KH-0005oO-AZ for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 10:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05646; Thu, 16 Oct 2003 10:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA9KE-0005WH-00; Thu, 16 Oct 2003 10:42:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA9KD-0005WE-00; Thu, 16 Oct 2003 10:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9KE-0005mW-CC; Thu, 16 Oct 2003 10:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9K6-0005ll-5i for simple@optimus.ietf.org; Thu, 16 Oct 2003 10:41:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05639 for ; Thu, 16 Oct 2003 10:41:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA9K3-0005Vz-00 for simple@ietf.org; Thu, 16 Oct 2003 10:41:51 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AA9K2-0005Vw-00 for simple@ietf.org; Thu, 16 Oct 2003 10:41:51 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9GEfieY060674; Thu, 16 Oct 2003 09:41:44 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8EAE1E.5000004@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] MSRP: Administrative shutdown of relays References: <2038BCC78B1AD641891A0D1AE133DBB701797293@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797293@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 09:41:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, October 14, 2003 12:18 AM >>To: Ben Campbell >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; >>simple@ietf.org >>Subject: Re: [Simple] MSRP: Administrative shutdown of relays >> >> >> >> >>Ben Campbell wrote: >> >>>I did not say it was good. I said I think we can live with >> >>it. That is >> >>>not the same thing. >>> >>>It seems to me we have 4 choices: >>> >>>1) Live with the potential for duplicate deliveries when a logical >>>conversation transitions from one session to another in a >> >>short time >> >>>period. Note that this can happen without relays being >> >>involved at all. >> >>>2) Require any hosting device that wishes to end a session >> >>wait either >> >>>until connected devices send a request, so that we can send >> >>a response >> >>>indicating that we are shutting down, or until an >> >>inactivity timeout >> >>>occurs. >>> >>>3) Allow relays to originate a message saying the session >> >>is going down. >> >>>4) Create a cross-session duplicate supression mechanism. >>> >>>3) and 4) seem awfully heavy-weight for the value they >> >>create. 2) either >> >>>puts a big burden on hosting device shutdown time, or >> >>requires us to >> >>>significantly shorten the timer value--which, as has been >> >>discussed at >> >>>length on this list, is also heavy-weight. >>> >>>Of these choices, I prefer option 1. >> >>I think you managed to summarize the choices quite well. >> >>I prefer either 2, or 4. Of those, 2 is the simpler, and I >>would be ok >>with reducing the timer value to make it responsive enough. >>OTOH, 4 also >>works in the case of a server crashing ungracefully, which 2 >>won't cover. >> >>I think 1 is a non-starter. We are all geeks, and can be tolerant of >>such misbehavior if we understand why it is happening. Others >>will not >>be so tolerant. They especially won't be tolerant if the >>message happens >>to be their 5gb movie. >> >>Now that I think about it, the 5gb message may be a reason to >>prefer 4. >>(Or 3): I don't think 2 works for that case. > > > > Is the relay required to receive the whole message before it can respond to it with a 5xx error response? To ask the same question froma client point of view: is the client expecting to send the whole message out before it receives a response? If the answer to both is no, then option 2 may still work. No, it is not. We already allow devices to interrupt a long message by sending an early response. That device must, however, also drop the connection, as framing is pretty much done for at this point. But given that Paul has agreed that option 1 does not introduce duplicate messages, why are we still considering option 2? Do you disagree with Paul's analysis? > > The problem remains that the relay has started forwarding the message, but it is being shutdown midway. In this case, we can either mandate the the relay must not be sutdown unless it has finished what it started, or the receiving end needs to tolerate receing the first part of a message again. > That is already implied by the ability to interrupt messages. > Regards, > Hisham > > >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 11:00:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06319; Thu, 16 Oct 2003 11:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9bf-0006iU-1K; Thu, 16 Oct 2003 11:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9bA-0006hg-JR for simple@optimus.ietf.org; Thu, 16 Oct 2003 10:59:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06262 for ; Thu, 16 Oct 2003 10:59:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA9b7-0005iL-00 for simple@ietf.org; Thu, 16 Oct 2003 10:59:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AA9b7-0005i6-00 for simple@ietf.org; Thu, 16 Oct 2003 10:59:29 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2003 07:59:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9GEwsFH010663; Thu, 16 Oct 2003 10:58:55 -0400 (EDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADE65241; Thu, 16 Oct 2003 10:58:53 -0400 (EDT) Message-ID: <3F8EB22D.6070409@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> <3F8D86DC.10007@cisco.com> <3F8E6723.2020702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 10:58:53 -0400 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi Paul, > > Thanks for the answers. I also had a closer look at the analysis you > sent in another email, and I think I understand the problem a little > better, and must agree it exists. > > But first off, I'd like to better understand what the requirements for > relay shutdown are. If there isn't a strict time window, the obvious > solution is for a relay to reject all new BINDs and VISITs until it has > no active sessions ongoing, and then shut down. I agree that we may need to clarify what the requirements are. But I doubt the approach you suggest is very practical. It isn't at all hard to imagine people keeping sessions open for extended periods of time - hours or even days. > If the administrator can't wait that long, then I would treat this more > as an error scenario rather than something we need to document in the > spec. A relay is supposed to host the session as long as it's active. Its hard to reconcile the possibility that users might want to keep sessions open for days with the practical necessity for adminstrators to manage their equipment. Imposing such a requirement would mean that the only viable implementation of a relay would be a fully redundant fault tolerant one. >> If the relay is shut down without advance notice of the application, >> there is certainly a chance that a message sent by the app will not >> arrive. If the application wants to survive the relay shutdown, then >> it will need to somehow detect the situation, establish a new >> connection, and retry the send. > > IMO, this behavior is not specified in the spec. Request timeouts are > interpreted as 5xx, which means the client will resend a few times and > then give up. > > We need text describing how and when an MSRP session transitions to a > new connection (or alternatively, someone can point me to the existing > text ;)) I agree that we need this. BTW, I think the need for this extends beyond MSRP. There is a need for a specification about how to recover from media errors in SIP. If you are talking on the phone and simply stop receiving media, I think you would like to have something done to try to remedy the problem. In the worst case you hang up and try again, but it would be nice for the UA to attempt something less extreme first. An obvious thing to do is to test the signaling channel - perhaps send a reinvite. If you know there are external resources involved then you might want to check them too - in this case the relay. If an external resource is broken, then you might want to update the call with a replacement. >> Relays shutting down gracefully, and timeouts on messages are simply >> ways for the application to learn what it needs to achieve its ends. >> Without some help, the application can't do this. > > Naturally, some help is also provided by the reliable connection the > MSRP runs on top of. Some, but not enough. Even with a single end-end reliable connection (like tcp), at the application level you typically don't know which bytes were delivered and which were not. >> SIP errs on the side of sending duplicates, and depends on the >> recipient to recognize and discard them. Doing the same in MSRP is >> the 4th choice in the vote. > > Right. I guess the difference in MSRP is that a TR-ID is only unique > within a connection. Does it need to be? Could option#4 simply be to > make TR-ID globally unique? Perhaps. But then I don't know how an application would decide when it could forget a TR-ID. >>> Why can't a relay simply peek at the first few bytes of message, >>> see if it is not a BIND or VISIT, and forward it byte-by-byte over >>> to the associated TCP connection. If there is trouble upstream, >>> simply mirror that trouble downstream. >> >> It can. It can also know that it is in the midst of forwarding a >> message. If it wants to shutdown before transmitting the last byte of >> the message, it can send an error response indicating this is what >> happened. > > Except that an MSRP client probably isn't expecting a response to a > request it is still in the process of sending? That is certainly something that would need to be clarified. But if one failed to check it would simply keep on writing until it finished, or until it started getting socket errors. So it might not handle things so gracefully. > Basically, the reason I'm raising these questions is that at least for > the non-relay case, I would like things to be as simple as in IRC. That > is, to send a message, you write it to a buffer and flush it. Granted, > the presence of relays will make things a bit more complicated, but > still we should avoid adding complexity unless it's absolutely necessary. Agreed it would be nice if it was simple. But some complexity is ok in my book to make it reliable. In the end this will get implemented in libraries I presume. Every application doesn't implement its own sip stack, so it shouldn't have to implement its own MSRP stack either. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 11:01:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06363 for ; Thu, 16 Oct 2003 11:01:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9cU-0006qD-Pm for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:00:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GF0sUV026291 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9cU-0006py-MA for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 11:00:54 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06319; Thu, 16 Oct 2003 11:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9bf-0006iU-1K; Thu, 16 Oct 2003 11:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA9bA-0006hg-JR for simple@optimus.ietf.org; Thu, 16 Oct 2003 10:59:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06262 for ; Thu, 16 Oct 2003 10:59:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA9b7-0005iL-00 for simple@ietf.org; Thu, 16 Oct 2003 10:59:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AA9b7-0005i6-00 for simple@ietf.org; Thu, 16 Oct 2003 10:59:29 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2003 07:59:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9GEwsFH010663; Thu, 16 Oct 2003 10:58:55 -0400 (EDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADE65241; Thu, 16 Oct 2003 10:58:53 -0400 (EDT) Message-ID: <3F8EB22D.6070409@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> <3F8D86DC.10007@cisco.com> <3F8E6723.2020702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 10:58:53 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi Paul, > > Thanks for the answers. I also had a closer look at the analysis you > sent in another email, and I think I understand the problem a little > better, and must agree it exists. > > But first off, I'd like to better understand what the requirements for > relay shutdown are. If there isn't a strict time window, the obvious > solution is for a relay to reject all new BINDs and VISITs until it has > no active sessions ongoing, and then shut down. I agree that we may need to clarify what the requirements are. But I doubt the approach you suggest is very practical. It isn't at all hard to imagine people keeping sessions open for extended periods of time - hours or even days. > If the administrator can't wait that long, then I would treat this more > as an error scenario rather than something we need to document in the > spec. A relay is supposed to host the session as long as it's active. Its hard to reconcile the possibility that users might want to keep sessions open for days with the practical necessity for adminstrators to manage their equipment. Imposing such a requirement would mean that the only viable implementation of a relay would be a fully redundant fault tolerant one. >> If the relay is shut down without advance notice of the application, >> there is certainly a chance that a message sent by the app will not >> arrive. If the application wants to survive the relay shutdown, then >> it will need to somehow detect the situation, establish a new >> connection, and retry the send. > > IMO, this behavior is not specified in the spec. Request timeouts are > interpreted as 5xx, which means the client will resend a few times and > then give up. > > We need text describing how and when an MSRP session transitions to a > new connection (or alternatively, someone can point me to the existing > text ;)) I agree that we need this. BTW, I think the need for this extends beyond MSRP. There is a need for a specification about how to recover from media errors in SIP. If you are talking on the phone and simply stop receiving media, I think you would like to have something done to try to remedy the problem. In the worst case you hang up and try again, but it would be nice for the UA to attempt something less extreme first. An obvious thing to do is to test the signaling channel - perhaps send a reinvite. If you know there are external resources involved then you might want to check them too - in this case the relay. If an external resource is broken, then you might want to update the call with a replacement. >> Relays shutting down gracefully, and timeouts on messages are simply >> ways for the application to learn what it needs to achieve its ends. >> Without some help, the application can't do this. > > Naturally, some help is also provided by the reliable connection the > MSRP runs on top of. Some, but not enough. Even with a single end-end reliable connection (like tcp), at the application level you typically don't know which bytes were delivered and which were not. >> SIP errs on the side of sending duplicates, and depends on the >> recipient to recognize and discard them. Doing the same in MSRP is >> the 4th choice in the vote. > > Right. I guess the difference in MSRP is that a TR-ID is only unique > within a connection. Does it need to be? Could option#4 simply be to > make TR-ID globally unique? Perhaps. But then I don't know how an application would decide when it could forget a TR-ID. >>> Why can't a relay simply peek at the first few bytes of message, >>> see if it is not a BIND or VISIT, and forward it byte-by-byte over >>> to the associated TCP connection. If there is trouble upstream, >>> simply mirror that trouble downstream. >> >> It can. It can also know that it is in the midst of forwarding a >> message. If it wants to shutdown before transmitting the last byte of >> the message, it can send an error response indicating this is what >> happened. > > Except that an MSRP client probably isn't expecting a response to a > request it is still in the process of sending? That is certainly something that would need to be clarified. But if one failed to check it would simply keep on writing until it finished, or until it started getting socket errors. So it might not handle things so gracefully. > Basically, the reason I'm raising these questions is that at least for > the non-relay case, I would like things to be as simple as in IRC. That > is, to send a message, you write it to a buffer and flush it. Granted, > the presence of relays will make things a bit more complicated, but > still we should avoid adding complexity unless it's absolutely necessary. Agreed it would be nice if it was simple. But some complexity is ok in my book to make it reliable. In the end this will get implemented in libraries I presume. Every application doesn't implement its own sip stack, so it shouldn't have to implement its own MSRP stack either. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 11:32:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07193; Thu, 16 Oct 2003 11:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA7a-0005z5-00; Thu, 16 Oct 2003 11:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAA7a-0005z2-00; Thu, 16 Oct 2003 11:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA7Y-0008VW-OH; Thu, 16 Oct 2003 11:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA6d-0008Oa-VS for simple@optimus.ietf.org; Thu, 16 Oct 2003 11:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07146 for ; Thu, 16 Oct 2003 11:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA6d-0005yV-00 for simple@ietf.org; Thu, 16 Oct 2003 11:32:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAA6b-0005yS-00 for simple@ietf.org; Thu, 16 Oct 2003 11:32:02 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9GFVneY064949; Thu, 16 Oct 2003 10:31:55 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8EB9DB.70102@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Paul Kyzivat , rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> <3F8D86DC.10007@cisco.com> <3F8E6723.2020702@nokia.com> In-Reply-To: <3F8E6723.2020702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 10:31:39 -0500 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi Paul, > > Thanks for the answers. I also had a closer look at the analysis you > sent in another email, and I think I understand the problem a little > better, and must agree it exists. > > But first off, I'd like to better understand what the requirements for > relay shutdown are. If there isn't a strict time window, the obvious > solution is for a relay to reject all new BINDs and VISITs until it has > no active sessions ongoing, and then shut down. That is exactly how it _would_ have worked when we were refreshing BIND and VISIT to keep a session alive. But we changed that mechanism to use SEND traffic. A session can stay alive indefinitely, with the relay never seeing another BIND or VISIT. > > If the administrator can't wait that long, then I would treat this more > as an error scenario rather than something we need to document in the > spec. A relay is supposed to host the session as long as it's active. > > So my answer would still be no but a few other things still bothering me > inline... > > On 15.10.2003 20:41, ext Paul Kyzivat: > >> >> aki.niemi@nokia.com wrote: >> >>> >>>> One: Do you believe it is important for the document to discuss >>>> administrative shutdown of relays. >>> >>> >>> No. And I'm going to have to ask a couple of stupid questions, too. >>> >>> >>> 1) Since duplicate delivery is the reason a relay would need to >>> care about shutting down gracefully in the first place, what are >>> the reasons a SEND would time out; who drops it; and why would an >>> MSRP endpoint retransmit if that happens? >> >> >> Lets look at application view first. The application has a message to >> send to the other end. Its responsibility is to ensure it gets >> there. It is using an MSRP connection to deliver the message. >> >> Meanwhile the operator of the relay needs to shut down relays from >> time to time. >> >> We want to ensure that the shutting down of the relay doesn't prevent >> the application from ensuring that the messages it sent get to the >> other end. >> >> If the relay is shut down without advance notice of the application, >> there is certainly a chance that a message sent by the app will not >> arrive. If the application wants to survive the relay shutdown, then >> it will need to somehow detect the situation, establish a new >> connection, and retry the send. > > > IMO, this behavior is not specified in the spec. Request timeouts are > interpreted as 5xx, which means the client will resend a few times and > then give up. It is not specified--but it is likely that some implementations will attempt to resume a session. Other implementations might simply tell the user that the session was ended, and the last message(s) may or may not have been delivered. > > We need text describing how and when an MSRP session transitions to a > new connection (or alternatively, someone can point me to the existing > text ;)) > Why? It is not our lot to define user experience, only to define protocol behavior. Different implementers may have entirely different requirements here. We assume that some implementers will attempt to auto-resume sessions. >> Relays shutting down gracefully, and timeouts on messages are simply >> ways for the application to learn what it needs to achieve its ends. >> Without some help, the application can't do this. > > > Naturally, some help is also provided by the reliable connection the > MSRP runs on top of. > Certainly this is true for some cases. But it cannot guarantee to me that in the case where I send a message and get no response, that I know that the opposite peer did not receive it. >>> 2) Isn't this identical to a proxy server forwarding a MESSAGE (via >>> TCP) and then shutting down? >> >> >> SIP errs on the side of sending duplicates, and depends on the >> recipient to recognize and discard them. Doing the same in MSRP is >> the 4th choice in the vote. > > > Right. I guess the difference in MSRP is that a TR-ID is only unique > within a connection. Does it need to be? Could option#4 simply be to > make TR-ID globally unique? That is what I had in mind _if_ we chose to pursue option 4. But it is more complex than just that--we would have to worry about how long a receivor had to remember what TR-IDs it had seen in the past. > >>> I thought this is what we wanted to avoid with MSRP. If a relay >>> also processes the SEND (i.e., receives it in entirety before >>> forwarding it along on another connection), this bases a big burden >>> on the relay when the SEND contains a 5GB movie. >> >> >> A relay clearly does "process" a SEND, but I don't think we have made >> any require that it receive the whole thing before forwarding it on. >> If that is what you mean we wanted to avoid, then I think we have. >> >>> Why can't a relay simply peek at the first few bytes of message, >>> see if it is not a BIND or VISIT, and forward it byte-by-byte over >>> to the associated TCP connection. If there is trouble upstream, >>> simply mirror that trouble downstream. >> >> >> It can. It can also know that it is in the midst of forwarding a >> message. If it wants to shutdown before transmitting the last byte of >> the message, it can send an error response indicating this is what >> happened. > > > Except that an MSRP client probably isn't expecting a response to a > request it is still in the process of sending? We already have the ability for the peer endpoint to interrupt a message with an early response. It does clobber framing for the connection, and therefore requires the peer to also close the connection. > >>> This way, there are never messages in-transit over relay(s) (with >>> the exception of a VISIT, which is always processed by a relay, but >>> can also be forwarded to another target). >> >> >> I don't see why this means there aren't messages in-transit. > > > You're right. The problem does not go away. Even though there might be > fewer states the system could be in, the relay could still shut down > when the request is pending - and the problem would remain. > > Basically, the reason I'm raising these questions is that at least for > the non-relay case, I would like things to be as simple as in IRC. That > is, to send a message, you write it to a buffer and flush it. Granted, > the presence of relays will make things a bit more complicated, but > still we should avoid adding complexity unless it's absolutely necessary. > > Regards, > Aki > >> Paul >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 11:33:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07234 for ; Thu, 16 Oct 2003 11:33:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA7c-00005j-Hi for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GFX4G7000345 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA7c-00005U-EC for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 11:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07193; Thu, 16 Oct 2003 11:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA7a-0005z5-00; Thu, 16 Oct 2003 11:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAA7a-0005z2-00; Thu, 16 Oct 2003 11:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA7Y-0008VW-OH; Thu, 16 Oct 2003 11:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA6d-0008Oa-VS for simple@optimus.ietf.org; Thu, 16 Oct 2003 11:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07146 for ; Thu, 16 Oct 2003 11:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA6d-0005yV-00 for simple@ietf.org; Thu, 16 Oct 2003 11:32:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAA6b-0005yS-00 for simple@ietf.org; Thu, 16 Oct 2003 11:32:02 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9GFVneY064949; Thu, 16 Oct 2003 10:31:55 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F8EB9DB.70102@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Paul Kyzivat , rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5926B@esebe013.ntc.nokia.com> <3F8D86DC.10007@cisco.com> <3F8E6723.2020702@nokia.com> In-Reply-To: <3F8E6723.2020702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 10:31:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi Paul, > > Thanks for the answers. I also had a closer look at the analysis you > sent in another email, and I think I understand the problem a little > better, and must agree it exists. > > But first off, I'd like to better understand what the requirements for > relay shutdown are. If there isn't a strict time window, the obvious > solution is for a relay to reject all new BINDs and VISITs until it has > no active sessions ongoing, and then shut down. That is exactly how it _would_ have worked when we were refreshing BIND and VISIT to keep a session alive. But we changed that mechanism to use SEND traffic. A session can stay alive indefinitely, with the relay never seeing another BIND or VISIT. > > If the administrator can't wait that long, then I would treat this more > as an error scenario rather than something we need to document in the > spec. A relay is supposed to host the session as long as it's active. > > So my answer would still be no but a few other things still bothering me > inline... > > On 15.10.2003 20:41, ext Paul Kyzivat: > >> >> aki.niemi@nokia.com wrote: >> >>> >>>> One: Do you believe it is important for the document to discuss >>>> administrative shutdown of relays. >>> >>> >>> No. And I'm going to have to ask a couple of stupid questions, too. >>> >>> >>> 1) Since duplicate delivery is the reason a relay would need to >>> care about shutting down gracefully in the first place, what are >>> the reasons a SEND would time out; who drops it; and why would an >>> MSRP endpoint retransmit if that happens? >> >> >> Lets look at application view first. The application has a message to >> send to the other end. Its responsibility is to ensure it gets >> there. It is using an MSRP connection to deliver the message. >> >> Meanwhile the operator of the relay needs to shut down relays from >> time to time. >> >> We want to ensure that the shutting down of the relay doesn't prevent >> the application from ensuring that the messages it sent get to the >> other end. >> >> If the relay is shut down without advance notice of the application, >> there is certainly a chance that a message sent by the app will not >> arrive. If the application wants to survive the relay shutdown, then >> it will need to somehow detect the situation, establish a new >> connection, and retry the send. > > > IMO, this behavior is not specified in the spec. Request timeouts are > interpreted as 5xx, which means the client will resend a few times and > then give up. It is not specified--but it is likely that some implementations will attempt to resume a session. Other implementations might simply tell the user that the session was ended, and the last message(s) may or may not have been delivered. > > We need text describing how and when an MSRP session transitions to a > new connection (or alternatively, someone can point me to the existing > text ;)) > Why? It is not our lot to define user experience, only to define protocol behavior. Different implementers may have entirely different requirements here. We assume that some implementers will attempt to auto-resume sessions. >> Relays shutting down gracefully, and timeouts on messages are simply >> ways for the application to learn what it needs to achieve its ends. >> Without some help, the application can't do this. > > > Naturally, some help is also provided by the reliable connection the > MSRP runs on top of. > Certainly this is true for some cases. But it cannot guarantee to me that in the case where I send a message and get no response, that I know that the opposite peer did not receive it. >>> 2) Isn't this identical to a proxy server forwarding a MESSAGE (via >>> TCP) and then shutting down? >> >> >> SIP errs on the side of sending duplicates, and depends on the >> recipient to recognize and discard them. Doing the same in MSRP is >> the 4th choice in the vote. > > > Right. I guess the difference in MSRP is that a TR-ID is only unique > within a connection. Does it need to be? Could option#4 simply be to > make TR-ID globally unique? That is what I had in mind _if_ we chose to pursue option 4. But it is more complex than just that--we would have to worry about how long a receivor had to remember what TR-IDs it had seen in the past. > >>> I thought this is what we wanted to avoid with MSRP. If a relay >>> also processes the SEND (i.e., receives it in entirety before >>> forwarding it along on another connection), this bases a big burden >>> on the relay when the SEND contains a 5GB movie. >> >> >> A relay clearly does "process" a SEND, but I don't think we have made >> any require that it receive the whole thing before forwarding it on. >> If that is what you mean we wanted to avoid, then I think we have. >> >>> Why can't a relay simply peek at the first few bytes of message, >>> see if it is not a BIND or VISIT, and forward it byte-by-byte over >>> to the associated TCP connection. If there is trouble upstream, >>> simply mirror that trouble downstream. >> >> >> It can. It can also know that it is in the midst of forwarding a >> message. If it wants to shutdown before transmitting the last byte of >> the message, it can send an error response indicating this is what >> happened. > > > Except that an MSRP client probably isn't expecting a response to a > request it is still in the process of sending? We already have the ability for the peer endpoint to interrupt a message with an early response. It does clobber framing for the connection, and therefore requires the peer to also close the connection. > >>> This way, there are never messages in-transit over relay(s) (with >>> the exception of a VISIT, which is always processed by a relay, but >>> can also be forwarded to another target). >> >> >> I don't see why this means there aren't messages in-transit. > > > You're right. The problem does not go away. Even though there might be > fewer states the system could be in, the relay could still shut down > when the request is pending - and the problem would remain. > > Basically, the reason I'm raising these questions is that at least for > the non-relay case, I would like things to be as simple as in IRC. That > is, to send a message, you write it to a buffer and flush it. Granted, > the presence of relays will make things a bit more complicated, but > still we should avoid adding complexity unless it's absolutely necessary. > > Regards, > Aki > >> Paul >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 11:56:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07912; Thu, 16 Oct 2003 11:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAU3-0006AM-00; Thu, 16 Oct 2003 11:56:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAU2-0006AJ-00; Thu, 16 Oct 2003 11:56:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAATp-0001Rw-Vt; Thu, 16 Oct 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAATS-0001RG-GB for simple@optimus.ietf.org; Thu, 16 Oct 2003 11:55:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07898 for ; Thu, 16 Oct 2003 11:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAATR-0006A3-00 for simple@ietf.org; Thu, 16 Oct 2003 11:55:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAATQ-0006A0-00 for simple@ietf.org; Thu, 16 Oct 2003 11:55:36 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GFtZX04600 for ; Thu, 16 Oct 2003 18:55:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 18:55:34 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 18:55:34 +0300 Message-ID: <3F8EBF76.9030901@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 15:55:34.0803 (UTC) FILETIME=[EF57E630:01C393FD] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments - specific issues Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 18:55:34 +0300 Content-Transfer-Encoding: 7bit Hi, I tried to make a truly thorough read of MSRP, and provide some comments on it. I didn't have time to go through the examples, though. Maybe next time ;) Here are first some specific issues about the draft. Mainly some corrections and clarifications. I will send a separate email with all of the nits I found in the draft. I will probably also send a couple of other emails each with a bit bigger issue I felt might be important to address separately. Regards, Aki --- - Chapter 1, 1st paragraph, last sentence: Should probably add that in page-mode, there is usually only an imaginative session, but messages are not related in any other way. Versus in session mode where there is a concrete relationship between messages. - Ch 2., 1st para., last sentence is confusing. No need to couple MSRP and SIP like that. - Ch 6.2, 3rd para., definition of the "both" direction is somehow confusing. It uses three names (host, visitor, answerer) for two entities. Need to make names consistent. - Ch 7, 2nd para.: Doesn't this spec only define use of TCP? Why this wording? - Ch 7.1.2, last para., When MSRP URL is communicated outside SDP, why would protocol need to be communicated, if the default is TCP, and MSRPS requires TLS? Wouldn't DNS SRV be enough here? - Ch 7.2, what is the extensibility model of MSRP? Should there be: Method = SEND / BIND / VISIT / other-method other-method = token - Ch 7.2, would be nice to have the ABNF definitions collected into one place instead of spread across chapters. - Ch 7.3, 3rd para., Why not make TR-ID global uniqueness be a MUST? That would help detect duplicate messages in case a relay crashes while SEND is pending, and the client resends the message. - Ch 7.4.1, bullet 1., Should clarify that the temporary, hard-to-guess property applies specifically to the "resource" part - Ch 7.4.1, bullet 4, What are the "circumstances" that would warrant the different timeout? Last sentence makes no sense to me. - Ch 7.4.1, 2nd set of bullets, paragraph after 3rd bullet, 2nd sentence: This sentence is really hard to parse. Suggest splitting it up to simplify. - Ch 7.4.3, 1st set of bullets, bullet 6, why is this needed (as opposed to just sending a 400)? The endpoints have already negotiated the set of allowed MIME types. Why add this dynamic removal, and is there a similar way to dynamicly add media types in a session? - Ch 7.4.3, 2nd set of bullets, 3rd bullet, same as above. - Ch 7.5.4, 3rd bullet, relay is supposed to send 500, but 500 is only defined as response for SEND. - Ch 7.6, 1st para., it states that MSRP digest doesn't support the realm. Why is that? In HTTP digest, realm is a textual string intended for the user to consume and to help select the correct username/password. - Ch 7.9.3, says "...usually in response to a digest authentication challenge." When else would this happen? - Ch 7.9.3, ABNF and definition for request-digest, SHA1 produces as output 160 bits (MD5 is 128bits), so this should be <"> 40LHEX <">. - Ch 7.9.4, text claims extensibility of authentication mechanism, but syntax only allows for "Digest". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 11:56:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07936 for ; Thu, 16 Oct 2003 11:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAU5-0001T9-14 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:56:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GFuGFU005641 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAU4-0001Su-Tz for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 11:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07912; Thu, 16 Oct 2003 11:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAU3-0006AM-00; Thu, 16 Oct 2003 11:56:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAU2-0006AJ-00; Thu, 16 Oct 2003 11:56:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAATp-0001Rw-Vt; Thu, 16 Oct 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAATS-0001RG-GB for simple@optimus.ietf.org; Thu, 16 Oct 2003 11:55:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07898 for ; Thu, 16 Oct 2003 11:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAATR-0006A3-00 for simple@ietf.org; Thu, 16 Oct 2003 11:55:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAATQ-0006A0-00 for simple@ietf.org; Thu, 16 Oct 2003 11:55:36 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GFtZX04600 for ; Thu, 16 Oct 2003 18:55:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 18:55:34 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 18:55:34 +0300 Message-ID: <3F8EBF76.9030901@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 15:55:34.0803 (UTC) FILETIME=[EF57E630:01C393FD] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments - specific issues Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 18:55:34 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I tried to make a truly thorough read of MSRP, and provide some comments on it. I didn't have time to go through the examples, though. Maybe next time ;) Here are first some specific issues about the draft. Mainly some corrections and clarifications. I will send a separate email with all of the nits I found in the draft. I will probably also send a couple of other emails each with a bit bigger issue I felt might be important to address separately. Regards, Aki --- - Chapter 1, 1st paragraph, last sentence: Should probably add that in page-mode, there is usually only an imaginative session, but messages are not related in any other way. Versus in session mode where there is a concrete relationship between messages. - Ch 2., 1st para., last sentence is confusing. No need to couple MSRP and SIP like that. - Ch 6.2, 3rd para., definition of the "both" direction is somehow confusing. It uses three names (host, visitor, answerer) for two entities. Need to make names consistent. - Ch 7, 2nd para.: Doesn't this spec only define use of TCP? Why this wording? - Ch 7.1.2, last para., When MSRP URL is communicated outside SDP, why would protocol need to be communicated, if the default is TCP, and MSRPS requires TLS? Wouldn't DNS SRV be enough here? - Ch 7.2, what is the extensibility model of MSRP? Should there be: Method = SEND / BIND / VISIT / other-method other-method = token - Ch 7.2, would be nice to have the ABNF definitions collected into one place instead of spread across chapters. - Ch 7.3, 3rd para., Why not make TR-ID global uniqueness be a MUST? That would help detect duplicate messages in case a relay crashes while SEND is pending, and the client resends the message. - Ch 7.4.1, bullet 1., Should clarify that the temporary, hard-to-guess property applies specifically to the "resource" part - Ch 7.4.1, bullet 4, What are the "circumstances" that would warrant the different timeout? Last sentence makes no sense to me. - Ch 7.4.1, 2nd set of bullets, paragraph after 3rd bullet, 2nd sentence: This sentence is really hard to parse. Suggest splitting it up to simplify. - Ch 7.4.3, 1st set of bullets, bullet 6, why is this needed (as opposed to just sending a 400)? The endpoints have already negotiated the set of allowed MIME types. Why add this dynamic removal, and is there a similar way to dynamicly add media types in a session? - Ch 7.4.3, 2nd set of bullets, 3rd bullet, same as above. - Ch 7.5.4, 3rd bullet, relay is supposed to send 500, but 500 is only defined as response for SEND. - Ch 7.6, 1st para., it states that MSRP digest doesn't support the realm. Why is that? In HTTP digest, realm is a textual string intended for the user to consume and to help select the correct username/password. - Ch 7.9.3, says "...usually in response to a digest authentication challenge." When else would this happen? - Ch 7.9.3, ABNF and definition for request-digest, SHA1 produces as output 160 bits (MD5 is 128bits), so this should be <"> 40LHEX <">. - Ch 7.9.4, text claims extensibility of authentication mechanism, but syntax only allows for "Digest". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 11:56:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07953; Thu, 16 Oct 2003 11:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAUm-0006Ah-00; Thu, 16 Oct 2003 11:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAUm-0006Ae-00; Thu, 16 Oct 2003 11:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAUm-0001Wk-LD; Thu, 16 Oct 2003 11:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAATs-0001S3-RK for simple@optimus.ietf.org; Thu, 16 Oct 2003 11:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07909 for ; Thu, 16 Oct 2003 11:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAATr-0006AG-00 for simple@ietf.org; Thu, 16 Oct 2003 11:56:03 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAATq-0006AC-00 for simple@ietf.org; Thu, 16 Oct 2003 11:56:03 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GFu1d04956 for ; Thu, 16 Oct 2003 18:56:01 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 18:56:01 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 18:56:01 +0300 Message-ID: <3F8EBF90.9050703@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 15:56:01.0193 (UTC) FILETIME=[FF12B190:01C393FD] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments - nits Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 18:56:00 +0300 Content-Transfer-Encoding: 7bit Hi, Here are some nits found for MSRP. Regards, Aki --- - Title needs to be spelled out. Maybe talk about MSRP there, too. - Abstract: need to spell out SDP and SIP. - Chapter 1, 1st paragraph, last sentence: page-mode -> Page-mode. - Ch 5.1, last para., first sentence: "...purpose in that the..." ^^^^ -> they - Ch 5.2, 1st para., 1st sentence: "...long messages on a..." ^^^ -> in - Ch 6.1, 3rd p., 2nd s.: "...indicates that the endpoint is may be..." remove "is" - Ch 6.2, 3rd p., ABNF doesn't allow "timeout" in "both", only in "passive". - Ch 6.3, 1st p., 3rd s., "Occasionally and endpoint..." ^^^ -> an - Ch 6.3, 3rd p., last s., "...both as a root body, or..." ^^^ -> and - Ch 6.4, 1st p., 2nd s., "...that is, contains a direction..." ^ -> insert "it" - Ch 6.4, 2nd p., last s., "meeting" -> "meaning" - Ch 6.5, 2nd p., 1st s., remove ";" from URL - Ch 7.2, some of the ABNF goes over 72 char lines. - Ch 7.4.1, bullet 4, remove double-quote after 3rd sentence - Ch 7.4.1, 2nd set of bullets, p. after bullet 3, 1st s., "...must choose whether of act..." ^^ -> to - Ch 7.4.4, 1st p., last s., "...or an a relay." ^^ -> on - Ch 7.4.4, 2nd p., 4th s., "...be sent host connection..." ^ insert "on the" - Ch 7.4.6, 1st p., 4ts s., "The connection hosting device..." ^ insert "between the" - Ch 7.5.1, 1st p., remove extra period at the end. - Ch 7.5.1, 2nd p., 1st s., "...constructs session URL." ^ the - Ch 7.5.1., 3rd bullet, "Expire" -> "Exp" - Ch 7.5.1, 2nd set of bullets, 2nd bullet, 3rd s., "...not duplicate URL..." ^ any - ..., 4th s., "...connect over a point..." ^^^^^ port - Ch 7.5.1, 2nd set of bullets, 3rd bullet, delete extra "section" - Ch 7.5.4, 7th bullet, "...subsequent arriving on... ^ requests - Ch 7.9.3, 1st p., 1st s., extra words "...endpoint to respond to offer..." ^^^^^^^^^^ - Ch 10.2, 1st para., 4th line, "...to acquire session URL..." ^ the _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 11:57:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07974 for ; Thu, 16 Oct 2003 11:57:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAUo-0001YY-Lz for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GFv21m005976 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 11:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAUo-0001YI-Ib for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 11:57:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07953; Thu, 16 Oct 2003 11:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAUm-0006Ah-00; Thu, 16 Oct 2003 11:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAUm-0006Ae-00; Thu, 16 Oct 2003 11:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAUm-0001Wk-LD; Thu, 16 Oct 2003 11:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAATs-0001S3-RK for simple@optimus.ietf.org; Thu, 16 Oct 2003 11:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07909 for ; Thu, 16 Oct 2003 11:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAATr-0006AG-00 for simple@ietf.org; Thu, 16 Oct 2003 11:56:03 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAATq-0006AC-00 for simple@ietf.org; Thu, 16 Oct 2003 11:56:03 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GFu1d04956 for ; Thu, 16 Oct 2003 18:56:01 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 18:56:01 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 18:56:01 +0300 Message-ID: <3F8EBF90.9050703@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 15:56:01.0193 (UTC) FILETIME=[FF12B190:01C393FD] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments - nits Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 18:56:00 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here are some nits found for MSRP. Regards, Aki --- - Title needs to be spelled out. Maybe talk about MSRP there, too. - Abstract: need to spell out SDP and SIP. - Chapter 1, 1st paragraph, last sentence: page-mode -> Page-mode. - Ch 5.1, last para., first sentence: "...purpose in that the..." ^^^^ -> they - Ch 5.2, 1st para., 1st sentence: "...long messages on a..." ^^^ -> in - Ch 6.1, 3rd p., 2nd s.: "...indicates that the endpoint is may be..." remove "is" - Ch 6.2, 3rd p., ABNF doesn't allow "timeout" in "both", only in "passive". - Ch 6.3, 1st p., 3rd s., "Occasionally and endpoint..." ^^^ -> an - Ch 6.3, 3rd p., last s., "...both as a root body, or..." ^^^ -> and - Ch 6.4, 1st p., 2nd s., "...that is, contains a direction..." ^ -> insert "it" - Ch 6.4, 2nd p., last s., "meeting" -> "meaning" - Ch 6.5, 2nd p., 1st s., remove ";" from URL - Ch 7.2, some of the ABNF goes over 72 char lines. - Ch 7.4.1, bullet 4, remove double-quote after 3rd sentence - Ch 7.4.1, 2nd set of bullets, p. after bullet 3, 1st s., "...must choose whether of act..." ^^ -> to - Ch 7.4.4, 1st p., last s., "...or an a relay." ^^ -> on - Ch 7.4.4, 2nd p., 4th s., "...be sent host connection..." ^ insert "on the" - Ch 7.4.6, 1st p., 4ts s., "The connection hosting device..." ^ insert "between the" - Ch 7.5.1, 1st p., remove extra period at the end. - Ch 7.5.1, 2nd p., 1st s., "...constructs session URL." ^ the - Ch 7.5.1., 3rd bullet, "Expire" -> "Exp" - Ch 7.5.1, 2nd set of bullets, 2nd bullet, 3rd s., "...not duplicate URL..." ^ any - ..., 4th s., "...connect over a point..." ^^^^^ port - Ch 7.5.1, 2nd set of bullets, 3rd bullet, delete extra "section" - Ch 7.5.4, 7th bullet, "...subsequent arriving on... ^ requests - Ch 7.9.3, 1st p., 1st s., extra words "...endpoint to respond to offer..." ^^^^^^^^^^ - Ch 10.2, 1st para., 4th line, "...to acquire session URL..." ^ the _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 12:03:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08168; Thu, 16 Oct 2003 12:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaq-0006EJ-00; Thu, 16 Oct 2003 12:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAao-0006EE-00; Thu, 16 Oct 2003 12:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAab-0002Fa-Ju; Thu, 16 Oct 2003 12:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAZi-00028I-J4 for simple@optimus.ietf.org; Thu, 16 Oct 2003 12:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08120 for ; Thu, 16 Oct 2003 12:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAZh-0006DI-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:05 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAAZg-0006D9-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:04 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GG1vX12085 for ; Thu, 16 Oct 2003 19:01:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 19:01:57 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 19:01:56 +0300 Message-ID: <3F8EC0F4.3080608@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 16:01:56.0710 (UTC) FILETIME=[D2FA4860:01C393FE] Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on MSRP - multiparty message session support Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 19:01:56 +0300 Content-Transfer-Encoding: 7bit Hi All, Since MSGFMT is no longer mandated (or is but only for CPIM gateways), how would a participant know where a message is coming from in a multiparty message session? Also, when using MSRP in a conferencing system, the lack of To/From prevents sending private messages efficiently within a multiparty session using an MSRP mixer as a "router" for them. So my question is this: what is the extensibility model for MSRP? For example, would it be possible to later on add this multiparty functionality as an extension, or would it be wise to think ahead already now? The draft includes some extensibility, e.g., for authentication algorithms, but I didn't immediately find much about adding methods and headers, and what to do with unknown headers. Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 12:03:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08172; Thu, 16 Oct 2003 12:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaq-0006EM-00; Thu, 16 Oct 2003 12:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAap-0006EF-00; Thu, 16 Oct 2003 12:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAac-0002Fl-91; Thu, 16 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAaF-0002AP-TX for simple@optimus.ietf.org; Thu, 16 Oct 2003 12:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08146 for ; Thu, 16 Oct 2003 12:02:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaE-0006Di-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaD-0006Df-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:38 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GG2ad12838 for ; Thu, 16 Oct 2003 19:02:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 19:02:35 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 19:02:35 +0300 Message-ID: <3F8EC11A.4050803@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 16:02:35.0553 (UTC) FILETIME=[EA214110:01C393FE] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments - Keepalive Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 19:02:34 +0300 Content-Transfer-Encoding: 7bit Hi, I know this is the sort of thing people usually use as flamebait, but I just have to ask ;-) Why overload the SEND for keepalive? Is there a specific reason to minimize the number of methods in this protocol? I don't see the complexity added by having a function that clearly does something specific have its own method name, too. Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 12:03:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08237 for ; Thu, 16 Oct 2003 12:03:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAas-0002Kp-Sk for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 12:03:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GG3I4M008976 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 12:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAas-0002Kh-L6 for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:03:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08168; Thu, 16 Oct 2003 12:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaq-0006EJ-00; Thu, 16 Oct 2003 12:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAao-0006EE-00; Thu, 16 Oct 2003 12:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAab-0002Fa-Ju; Thu, 16 Oct 2003 12:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAZi-00028I-J4 for simple@optimus.ietf.org; Thu, 16 Oct 2003 12:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08120 for ; Thu, 16 Oct 2003 12:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAZh-0006DI-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:05 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAAZg-0006D9-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:04 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GG1vX12085 for ; Thu, 16 Oct 2003 19:01:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 19:01:57 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 19:01:56 +0300 Message-ID: <3F8EC0F4.3080608@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 16:01:56.0710 (UTC) FILETIME=[D2FA4860:01C393FE] Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on MSRP - multiparty message session support Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 19:01:56 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, Since MSGFMT is no longer mandated (or is but only for CPIM gateways), how would a participant know where a message is coming from in a multiparty message session? Also, when using MSRP in a conferencing system, the lack of To/From prevents sending private messages efficiently within a multiparty session using an MSRP mixer as a "router" for them. So my question is this: what is the extensibility model for MSRP? For example, would it be possible to later on add this multiparty functionality as an extension, or would it be wise to think ahead already now? The draft includes some extensibility, e.g., for authentication algorithms, but I didn't immediately find much about adding methods and headers, and what to do with unknown headers. Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 12:03:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08240 for ; Thu, 16 Oct 2003 12:03:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAat-0002LW-89 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 12:03:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GG3JUN009010 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 12:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAat-0002LE-3O for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08172; Thu, 16 Oct 2003 12:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaq-0006EM-00; Thu, 16 Oct 2003 12:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAap-0006EF-00; Thu, 16 Oct 2003 12:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAac-0002Fl-91; Thu, 16 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAaF-0002AP-TX for simple@optimus.ietf.org; Thu, 16 Oct 2003 12:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08146 for ; Thu, 16 Oct 2003 12:02:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaE-0006Di-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaD-0006Df-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:38 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GG2ad12838 for ; Thu, 16 Oct 2003 19:02:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 19:02:35 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 19:02:35 +0300 Message-ID: <3F8EC11A.4050803@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 16:02:35.0553 (UTC) FILETIME=[EA214110:01C393FE] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments - Keepalive Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 19:02:34 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I know this is the sort of thing people usually use as flamebait, but I just have to ask ;-) Why overload the SEND for keepalive? Is there a specific reason to minimize the number of methods in this protocol? I don't see the complexity added by having a function that clearly does something specific have its own method name, too. Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 16 12:52:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08239 for ; Thu, 16 Oct 2003 12:03:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAat-0002LF-3c for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 12:03:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GG3JPL008994 for simple-archive@odin.ietf.org; Thu, 16 Oct 2003 12:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAas-0002Ks-Uo for simple-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:03:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAB08174; Thu, 16 Oct 2003 12:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaq-0006EP-00; Thu, 16 Oct 2003 12:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAap-0006EG-00; Thu, 16 Oct 2003 12:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAac-0002Ft-LU; Thu, 16 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAaI-0002AU-1B for simple@optimus.ietf.org; Thu, 16 Oct 2003 12:02:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08149 for ; Thu, 16 Oct 2003 12:02:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaG-0006Dn-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaC-0006Dd-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:40 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GG2UX13039 for ; Thu, 16 Oct 2003 19:02:31 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 19:02:30 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 19:02:30 +0300 Message-ID: <3F8EC115.4090305@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 16:02:30.0459 (UTC) FILETIME=[E717F8B0:01C393FE] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP comments - request/response handling and retrying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 19:02:29 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In the draft, if a SEND times out, the MSRP client is supposed to handle this as if a 5xx was received. I.e., it will resend the message a few times and then quit the session. In case the other endpoint is in the midst of sending a large message, a response may take longer than the request time out value. This will result in a number of duplicate messages received. There should be a better way to handle this. Why resend in the first place, especially if the connection is active? Also, what is the motivation for making retransmissions with a different TR-ID? Doesn't this go agains the idea of retrying the request? Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 16 12:52:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAB08174; Thu, 16 Oct 2003 12:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaq-0006EP-00; Thu, 16 Oct 2003 12:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAap-0006EG-00; Thu, 16 Oct 2003 12:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAac-0002Ft-LU; Thu, 16 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAaI-0002AU-1B for simple@optimus.ietf.org; Thu, 16 Oct 2003 12:02:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08149 for ; Thu, 16 Oct 2003 12:02:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaG-0006Dn-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAAaC-0006Dd-00 for simple@ietf.org; Thu, 16 Oct 2003 12:02:40 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9GG2UX13039 for ; Thu, 16 Oct 2003 19:02:31 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Oct 2003 19:02:30 +0300 Received: from nokia.com ([172.21.11.223]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 19:02:30 +0300 Message-ID: <3F8EC115.4090305@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2003 16:02:30.0459 (UTC) FILETIME=[E717F8B0:01C393FE] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP comments - request/response handling and retrying Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 19:02:29 +0300 Content-Transfer-Encoding: 7bit Hi, In the draft, if a SEND times out, the MSRP client is supposed to handle this as if a 5xx was received. I.e., it will resend the message a few times and then quit the session. In case the other endpoint is in the midst of sending a large message, a response may take longer than the request time out value. This will result in a number of duplicate messages received. There should be a better way to handle this. Why resend in the first place, especially if the connection is active? Also, what is the motivation for making retransmissions with a different TR-ID? Doesn't this go agains the idea of retrying the request? Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 05:25:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25519; Fri, 17 Oct 2003 05:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQs0-0001Cl-00; Fri, 17 Oct 2003 05:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAQs0-0001Cg-00; Fri, 17 Oct 2003 05:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQry-00025P-L4; Fri, 17 Oct 2003 05:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQqy-000214-SZ for simple@optimus.ietf.org; Fri, 17 Oct 2003 05:25:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25494 for ; Fri, 17 Oct 2003 05:24:49 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQqu-0001By-00 for simple@ietf.org; Fri, 17 Oct 2003 05:24:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAQqu-0001Bv-00 for simple@ietf.org; Fri, 17 Oct 2003 05:24:56 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9H9OtX17990 for ; Fri, 17 Oct 2003 12:24:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 12:24:55 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 12:24:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9094@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOT9ggZwrqwlJPyQjGBBiZOUxnFNAAmY7Rw To: Cc: , X-OriginalArrivalTime: 17 Oct 2003 09:24:53.0715 (UTC) FILETIME=[85C77A30:01C39490] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:24:53 +0300 Content-Transfer-Encoding: quoted-printable Hi Paul, Paul wrote: > > Right. I guess the difference in MSRP is that a TR-ID is=20 > only unique=20 > > within a connection. Does it need to be? Could option#4=20 > simply be to=20 > > make TR-ID globally unique? >=20 > Perhaps. But then I don't know how an application would=20 > decide when it=20 > could forget a TR-ID. I'm not sure if there needs to be anything additional to how it = currently stands. It is currently scoped within a given session, with = SHOULD strength global uniqueness. My interpretation is that the = application needs to remember all TR-IDs used in a given session, up = until a response to those requests is received. Here, I understood "session" to mean the session initiated using SIP. = This would normally be equal to the MSRP session (or connection), but of = course if clients automatically reconnect due to failure, "session" = would span over multiple MSRP connections.h Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 05:26:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25535 for ; Fri, 17 Oct 2003 05:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQs6-00026H-Q7 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 05:26:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H9QAT6008072 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 05:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQs6-000267-Bj for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 05:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25519; Fri, 17 Oct 2003 05:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQs0-0001Cl-00; Fri, 17 Oct 2003 05:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAQs0-0001Cg-00; Fri, 17 Oct 2003 05:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQry-00025P-L4; Fri, 17 Oct 2003 05:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQqy-000214-SZ for simple@optimus.ietf.org; Fri, 17 Oct 2003 05:25:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25494 for ; Fri, 17 Oct 2003 05:24:49 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQqu-0001By-00 for simple@ietf.org; Fri, 17 Oct 2003 05:24:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAQqu-0001Bv-00 for simple@ietf.org; Fri, 17 Oct 2003 05:24:56 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9H9OtX17990 for ; Fri, 17 Oct 2003 12:24:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 12:24:55 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 12:24:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9094@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOT9ggZwrqwlJPyQjGBBiZOUxnFNAAmY7Rw To: Cc: , X-OriginalArrivalTime: 17 Oct 2003 09:24:53.0715 (UTC) FILETIME=[85C77A30:01C39490] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:24:53 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Paul, Paul wrote: > > Right. I guess the difference in MSRP is that a TR-ID is=20 > only unique=20 > > within a connection. Does it need to be? Could option#4=20 > simply be to=20 > > make TR-ID globally unique? >=20 > Perhaps. But then I don't know how an application would=20 > decide when it=20 > could forget a TR-ID. I'm not sure if there needs to be anything additional to how it = currently stands. It is currently scoped within a given session, with = SHOULD strength global uniqueness. My interpretation is that the = application needs to remember all TR-IDs used in a given session, up = until a response to those requests is received. Here, I understood "session" to mean the session initiated using SIP. = This would normally be equal to the MSRP session (or connection), but of = course if clients automatically reconnect due to failure, "session" = would span over multiple MSRP connections.h Regards, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 05:47:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25918; Fri, 17 Oct 2003 05:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AARDI-0001Nu-00; Fri, 17 Oct 2003 05:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AARDI-0001Nr-00; Fri, 17 Oct 2003 05:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AARDF-0002tE-8v; Fri, 17 Oct 2003 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AARCl-0002sl-Mm for simple@optimus.ietf.org; Fri, 17 Oct 2003 05:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25914 for ; Fri, 17 Oct 2003 05:47:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AARCh-0001Nf-00 for simple@ietf.org; Fri, 17 Oct 2003 05:47:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AARCg-0001Nc-00 for simple@ietf.org; Fri, 17 Oct 2003 05:47:27 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9H9lRd09634 for ; Fri, 17 Oct 2003 12:47:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 12:47:19 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 12:47:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOT+rAdOCuezMKGSne3ymZLEMwvWgAkus3g To: Cc: , , X-OriginalArrivalTime: 17 Oct 2003 09:47:19.0631 (UTC) FILETIME=[A801F5F0:01C39493] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:47:19 +0300 Content-Transfer-Encoding: quoted-printable Hi Ben, Inline. > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] [snip] > >> If the relay is shut down without advance notice of the=20 > application, > >> there is certainly a chance that a message sent by the=20 > app will not > >> arrive. If the application wants to survive the relay=20 > shutdown, then > >> it will need to somehow detect the situation, establish a new > >> connection, and retry the send. > >=20 > >=20 > > IMO, this behavior is not specified in the spec. Request=20 > timeouts are=20 > > interpreted as 5xx, which means the client will resend a=20 > few times and=20 > > then give up. >=20 > It is not specified--but it is likely that some implementations will=20 > attempt to resume a session. Other implementations might=20 > simply tell the=20 > user that the session was ended, and the last message(s) may=20 > or may not=20 > have been delivered. Is this acceptable? A lot of the discussion so far has made the = assumption that an MSRP client would reconnect and resend if there is a = timeout, a 5xx, or the connection to the relay closes. That isn't the = defined behavior, it actually goes against the defined behavior. Bullet 5, Ch 7.4.3: If the endpoint receives 5xx responses more than some threshold number of times in a row, it SHOULD assume the session has failed, and initiate tear-down via the signaling protocol. =20 > >=20 > > We need text describing how and when an MSRP session=20 > transitions to a=20 > > new connection (or alternatively, someone can point me to=20 > the existing=20 > > text ;)) > >=20 >=20 > Why? It is not our lot to define user experience, only to define=20 > protocol behavior. Different implementers may have entirely=20 > different=20 > requirements here. We assume that some implementers will attempt to=20 > auto-resume sessions. What do you mean by auto-resume? I am not talking about user experience = here. I believe it is protocol behavior to describe what happens when a = SEND times out, or a 5xx is received. Currently the behavior is that a = client MAY retransmit, then quits the session. If the client may also = reconnect and resend, then that needs to be included as well. =20 > >> Relays shutting down gracefully, and timeouts on messages=20 > are simply > >> ways for the application to learn what it needs to=20 > achieve its ends. > >> Without some help, the application can't do this. > >=20 > >=20 > > Naturally, some help is also provided by the reliable=20 > connection the=20 > > MSRP runs on top of. > > >=20 > Certainly this is true for some cases. But it cannot guarantee to me=20 > that in the case where I send a message and get no response,=20 > that I know=20 > that the opposite peer did not receive it. True. But it can give you a certain amount of more confidence that if a = SEND times out, gets a 5xx, a retransmission will likely not give a = better result, as opposed to if we were running MSRP over an unreliable = transport. Regards, Aki =20 > >>> 2) Isn't this identical to a proxy server forwarding a=20 > MESSAGE (via > >>> TCP) and then shutting down? > >> > >> > >> SIP errs on the side of sending duplicates, and depends on the > >> recipient to recognize and discard them. Doing the same in MSRP is > >> the 4th choice in the vote. > >=20 > >=20 > > Right. I guess the difference in MSRP is that a TR-ID is=20 > only unique=20 > > within a connection. Does it need to be? Could option#4=20 > simply be to=20 > > make TR-ID globally unique? >=20 > That is what I had in mind _if_ we chose to pursue option 4.=20 > But it is=20 > more complex than just that--we would have to worry about how long a=20 > receivor had to remember what TR-IDs it had seen in the past. >=20 > >=20 > >>> I thought this is what we wanted to avoid with MSRP. If a relay > >>> also processes the SEND (i.e., receives it in entirety before > >>> forwarding it along on another connection), this bases a=20 > big burden > >>> on the relay when the SEND contains a 5GB movie. > >> > >> > >> A relay clearly does "process" a SEND, but I don't think=20 > we have made > >> any require that it receive the whole thing before=20 > forwarding it on. > >> If that is what you mean we wanted to avoid, then I think we have. > >> > >>> Why can't a relay simply peek at the first few bytes of message, > >>> see if it is not a BIND or VISIT, and forward it=20 > byte-by-byte over > >>> to the associated TCP connection. If there is trouble upstream, > >>> simply mirror that trouble downstream. > >> > >> > >> It can. It can also know that it is in the midst of forwarding a=20 > >> message. If it wants to shutdown before transmitting the=20 > last byte of > >> the message, it can send an error response indicating=20 > this is what > >> happened. > >=20 > >=20 > > Except that an MSRP client probably isn't expecting a=20 > response to a=20 > > request it is still in the process of sending? >=20 > We already have the ability for the peer endpoint to=20 > interrupt a message=20 > with an early response. It does clobber framing for the=20 > connection, and=20 > therefore requires the peer to also close the connection. I didn't see this spelled out anywhere in the draft. Regards, Aki > >=20 > >>> This way, there are never messages in-transit over relay(s) (with > >>> the exception of a VISIT, which is always processed by a=20 > relay, but > >>> can also be forwarded to another target). > >> > >> > >> I don't see why this means there aren't messages in-transit. > >=20 > >=20 > > You're right. The problem does not go away. Even though=20 > there might be=20 > > fewer states the system could be in, the relay could still=20 > shut down=20 > > when the request is pending - and the problem would remain. > >=20 > > Basically, the reason I'm raising these questions is that=20 > at least for=20 > > the non-relay case, I would like things to be as simple as=20 > in IRC. That=20 > > is, to send a message, you write it to a buffer and flush=20 > it. Granted,=20 > > the presence of relays will make things a bit more=20 > complicated, but=20 > > still we should avoid adding complexity unless it's=20 > absolutely necessary. > >=20 > > Regards, > > Aki > >=20 > >> Paul > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 05:48:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25937 for ; Fri, 17 Oct 2003 05:48:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AARDM-0002u5-RK for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 05:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H9m8KB011155 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 05:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AARDM-0002tq-Kr for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 05:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25918; Fri, 17 Oct 2003 05:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AARDI-0001Nu-00; Fri, 17 Oct 2003 05:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AARDI-0001Nr-00; Fri, 17 Oct 2003 05:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AARDF-0002tE-8v; Fri, 17 Oct 2003 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AARCl-0002sl-Mm for simple@optimus.ietf.org; Fri, 17 Oct 2003 05:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25914 for ; Fri, 17 Oct 2003 05:47:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AARCh-0001Nf-00 for simple@ietf.org; Fri, 17 Oct 2003 05:47:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AARCg-0001Nc-00 for simple@ietf.org; Fri, 17 Oct 2003 05:47:27 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9H9lRd09634 for ; Fri, 17 Oct 2003 12:47:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 12:47:19 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 12:47:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays) Thread-Index: AcOT+rAdOCuezMKGSne3ymZLEMwvWgAkus3g To: Cc: , , X-OriginalArrivalTime: 17 Oct 2003 09:47:19.0631 (UTC) FILETIME=[A801F5F0:01C39493] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:47:19 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ben, Inline. > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] [snip] > >> If the relay is shut down without advance notice of the=20 > application, > >> there is certainly a chance that a message sent by the=20 > app will not > >> arrive. If the application wants to survive the relay=20 > shutdown, then > >> it will need to somehow detect the situation, establish a new > >> connection, and retry the send. > >=20 > >=20 > > IMO, this behavior is not specified in the spec. Request=20 > timeouts are=20 > > interpreted as 5xx, which means the client will resend a=20 > few times and=20 > > then give up. >=20 > It is not specified--but it is likely that some implementations will=20 > attempt to resume a session. Other implementations might=20 > simply tell the=20 > user that the session was ended, and the last message(s) may=20 > or may not=20 > have been delivered. Is this acceptable? A lot of the discussion so far has made the = assumption that an MSRP client would reconnect and resend if there is a = timeout, a 5xx, or the connection to the relay closes. That isn't the = defined behavior, it actually goes against the defined behavior. Bullet 5, Ch 7.4.3: If the endpoint receives 5xx responses more than some threshold number of times in a row, it SHOULD assume the session has failed, and initiate tear-down via the signaling protocol. =20 > >=20 > > We need text describing how and when an MSRP session=20 > transitions to a=20 > > new connection (or alternatively, someone can point me to=20 > the existing=20 > > text ;)) > >=20 >=20 > Why? It is not our lot to define user experience, only to define=20 > protocol behavior. Different implementers may have entirely=20 > different=20 > requirements here. We assume that some implementers will attempt to=20 > auto-resume sessions. What do you mean by auto-resume? I am not talking about user experience = here. I believe it is protocol behavior to describe what happens when a = SEND times out, or a 5xx is received. Currently the behavior is that a = client MAY retransmit, then quits the session. If the client may also = reconnect and resend, then that needs to be included as well. =20 > >> Relays shutting down gracefully, and timeouts on messages=20 > are simply > >> ways for the application to learn what it needs to=20 > achieve its ends. > >> Without some help, the application can't do this. > >=20 > >=20 > > Naturally, some help is also provided by the reliable=20 > connection the=20 > > MSRP runs on top of. > > >=20 > Certainly this is true for some cases. But it cannot guarantee to me=20 > that in the case where I send a message and get no response,=20 > that I know=20 > that the opposite peer did not receive it. True. But it can give you a certain amount of more confidence that if a = SEND times out, gets a 5xx, a retransmission will likely not give a = better result, as opposed to if we were running MSRP over an unreliable = transport. Regards, Aki =20 > >>> 2) Isn't this identical to a proxy server forwarding a=20 > MESSAGE (via > >>> TCP) and then shutting down? > >> > >> > >> SIP errs on the side of sending duplicates, and depends on the > >> recipient to recognize and discard them. Doing the same in MSRP is > >> the 4th choice in the vote. > >=20 > >=20 > > Right. I guess the difference in MSRP is that a TR-ID is=20 > only unique=20 > > within a connection. Does it need to be? Could option#4=20 > simply be to=20 > > make TR-ID globally unique? >=20 > That is what I had in mind _if_ we chose to pursue option 4.=20 > But it is=20 > more complex than just that--we would have to worry about how long a=20 > receivor had to remember what TR-IDs it had seen in the past. >=20 > >=20 > >>> I thought this is what we wanted to avoid with MSRP. If a relay > >>> also processes the SEND (i.e., receives it in entirety before > >>> forwarding it along on another connection), this bases a=20 > big burden > >>> on the relay when the SEND contains a 5GB movie. > >> > >> > >> A relay clearly does "process" a SEND, but I don't think=20 > we have made > >> any require that it receive the whole thing before=20 > forwarding it on. > >> If that is what you mean we wanted to avoid, then I think we have. > >> > >>> Why can't a relay simply peek at the first few bytes of message, > >>> see if it is not a BIND or VISIT, and forward it=20 > byte-by-byte over > >>> to the associated TCP connection. If there is trouble upstream, > >>> simply mirror that trouble downstream. > >> > >> > >> It can. It can also know that it is in the midst of forwarding a=20 > >> message. If it wants to shutdown before transmitting the=20 > last byte of > >> the message, it can send an error response indicating=20 > this is what > >> happened. > >=20 > >=20 > > Except that an MSRP client probably isn't expecting a=20 > response to a=20 > > request it is still in the process of sending? >=20 > We already have the ability for the peer endpoint to=20 > interrupt a message=20 > with an early response. It does clobber framing for the=20 > connection, and=20 > therefore requires the peer to also close the connection. I didn't see this spelled out anywhere in the draft. Regards, Aki > >=20 > >>> This way, there are never messages in-transit over relay(s) (with > >>> the exception of a VISIT, which is always processed by a=20 > relay, but > >>> can also be forwarded to another target). > >> > >> > >> I don't see why this means there aren't messages in-transit. > >=20 > >=20 > > You're right. The problem does not go away. Even though=20 > there might be=20 > > fewer states the system could be in, the relay could still=20 > shut down=20 > > when the request is pending - and the problem would remain. > >=20 > > Basically, the reason I'm raising these questions is that=20 > at least for=20 > > the non-relay case, I would like things to be as simple as=20 > in IRC. That=20 > > is, to send a message, you write it to a buffer and flush=20 > it. Granted,=20 > > the presence of relays will make things a bit more=20 > complicated, but=20 > > still we should avoid adding complexity unless it's=20 > absolutely necessary. > >=20 > > Regards, > > Aki > >=20 > >> Paul > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 10:35:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04692; Fri, 17 Oct 2003 10:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVhA-0003zx-00; Fri, 17 Oct 2003 10:35:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAVh9-0003zu-00; Fri, 17 Oct 2003 10:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVh1-00086C-HJ; Fri, 17 Oct 2003 10:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVgf-00085j-0A for simple@optimus.ietf.org; Fri, 17 Oct 2003 10:34:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04673 for ; Fri, 17 Oct 2003 10:34:30 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVgc-0003zT-00 for simple@ietf.org; Fri, 17 Oct 2003 10:34:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAVgb-0003zQ-00 for simple@ietf.org; Fri, 17 Oct 2003 10:34:38 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HEYad01379 for ; Fri, 17 Oct 2003 17:34:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 Oct 2003 17:34:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 17:34:34 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 17:34:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on MSRP - multiparty message session support Message-ID: Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOT/y3Pb0sOpQayREaJ+cP2OxUygwAut/vw To: , X-OriginalArrivalTime: 17 Oct 2003 14:34:32.0862 (UTC) FILETIME=[C7D053E0:01C394BB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 17:34:32 +0300 Content-Transfer-Encoding: quoted-printable Hi, I think Aki has a very important point here. I would say that one of the = essential drivers for having messaging sessions in the first place is = the ability to use them as "media" in the SIP conferencing framework (or = in the centralized conferencing a la XCON). In these kind of "chats" it = is obviously mandatory that the recipients sees who the originator is. = (BTW, this is one of the SIP services that also 3GPP is working on.) I see three ways forward: 1. Fix this in MSRP base spec (I see that many people woudn't want this = anymore at this stage, but still...) 2. Define how MSRP can be extended and do this ASAP as the first = extension 3. Use MSGFMT somehow to support this feature My strong opinion is that MSRP should not allowed to proceed to IESG = before there is some conclusion on this. At least to me MSRP without a = simple way to support the conference scenario is worthless. There are = already have plenty of solutions to send messages between two end-points = and imitate a "session" (even SMS can do this), but SIP/MSRP solution's = strenght should be really the multi-party case. Markus=20 > -----Original Message----- > From: ext Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: 16 October, 2003 19:02 > To: simple@ietf.org > Subject: [Simple] Comments on MSRP - multiparty message=20 > session support >=20 >=20 > Hi All, >=20 > Since MSGFMT is no longer mandated (or is but only for CPIM=20 > gateways),=20 > how would a participant know where a message is coming from in a=20 > multiparty message session? >=20 > Also, when using MSRP in a conferencing system, the lack of To/From=20 > prevents sending private messages efficiently within a multiparty=20 > session using an MSRP mixer as a "router" for them. >=20 > So my question is this: what is the extensibility model for MSRP? For=20 > example, would it be possible to later on add this multiparty=20 > functionality as an extension, or would it be wise to think ahead=20 > already now? >=20 > The draft includes some extensibility, e.g., for authentication=20 > algorithms, but I didn't immediately find much about adding=20 > methods and=20 > headers, and what to do with unknown headers. >=20 > Regards, > Aki >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 10:35:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04715 for ; Fri, 17 Oct 2003 10:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVhD-00087G-6a for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 10:35:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HEZFQX031194 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 10:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVhD-000873-32 for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 10:35:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04692; Fri, 17 Oct 2003 10:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVhA-0003zx-00; Fri, 17 Oct 2003 10:35:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAVh9-0003zu-00; Fri, 17 Oct 2003 10:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVh1-00086C-HJ; Fri, 17 Oct 2003 10:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVgf-00085j-0A for simple@optimus.ietf.org; Fri, 17 Oct 2003 10:34:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04673 for ; Fri, 17 Oct 2003 10:34:30 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVgc-0003zT-00 for simple@ietf.org; Fri, 17 Oct 2003 10:34:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAVgb-0003zQ-00 for simple@ietf.org; Fri, 17 Oct 2003 10:34:38 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HEYad01379 for ; Fri, 17 Oct 2003 17:34:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 Oct 2003 17:34:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 17:34:34 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 17:34:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on MSRP - multiparty message session support Message-ID: Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOT/y3Pb0sOpQayREaJ+cP2OxUygwAut/vw To: , X-OriginalArrivalTime: 17 Oct 2003 14:34:32.0862 (UTC) FILETIME=[C7D053E0:01C394BB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 17:34:32 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I think Aki has a very important point here. I would say that one of the = essential drivers for having messaging sessions in the first place is = the ability to use them as "media" in the SIP conferencing framework (or = in the centralized conferencing a la XCON). In these kind of "chats" it = is obviously mandatory that the recipients sees who the originator is. = (BTW, this is one of the SIP services that also 3GPP is working on.) I see three ways forward: 1. Fix this in MSRP base spec (I see that many people woudn't want this = anymore at this stage, but still...) 2. Define how MSRP can be extended and do this ASAP as the first = extension 3. Use MSGFMT somehow to support this feature My strong opinion is that MSRP should not allowed to proceed to IESG = before there is some conclusion on this. At least to me MSRP without a = simple way to support the conference scenario is worthless. There are = already have plenty of solutions to send messages between two end-points = and imitate a "session" (even SMS can do this), but SIP/MSRP solution's = strenght should be really the multi-party case. Markus=20 > -----Original Message----- > From: ext Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: 16 October, 2003 19:02 > To: simple@ietf.org > Subject: [Simple] Comments on MSRP - multiparty message=20 > session support >=20 >=20 > Hi All, >=20 > Since MSGFMT is no longer mandated (or is but only for CPIM=20 > gateways),=20 > how would a participant know where a message is coming from in a=20 > multiparty message session? >=20 > Also, when using MSRP in a conferencing system, the lack of To/From=20 > prevents sending private messages efficiently within a multiparty=20 > session using an MSRP mixer as a "router" for them. >=20 > So my question is this: what is the extensibility model for MSRP? For=20 > example, would it be possible to later on add this multiparty=20 > functionality as an extension, or would it be wise to think ahead=20 > already now? >=20 > The draft includes some extensibility, e.g., for authentication=20 > algorithms, but I didn't immediately find much about adding=20 > methods and=20 > headers, and what to do with unknown headers. >=20 > Regards, > Aki >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 11:15:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05890; Fri, 17 Oct 2003 11:15:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWJw-0004JR-00; Fri, 17 Oct 2003 11:15:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAWJw-0004JO-00; Fri, 17 Oct 2003 11:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWJj-0001aB-6d; Fri, 17 Oct 2003 11:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWJR-0001ZU-U5 for simple@optimus.ietf.org; Fri, 17 Oct 2003 11:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05858 for ; Fri, 17 Oct 2003 11:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWJR-0004Iq-00 for simple@ietf.org; Fri, 17 Oct 2003 11:14:45 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAWJQ-0004In-00 for simple@ietf.org; Fri, 17 Oct 2003 11:14:44 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HFEHeY075263; Fri, 17 Oct 2003 10:14:28 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F90073E.709@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 10:14:06 -0500 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: [...] > Is this acceptable? A lot of the discussion so far has made the assumption that an MSRP client would reconnect and resend if there is a timeout, a 5xx, or the connection to the relay closes. That isn't the defined behavior, it actually goes against the defined behavior. > > Bullet 5, Ch 7.4.3: > > If the endpoint receives 5xx responses more than some threshold > number of times in a row, it SHOULD assume the session has > failed, and initiate tear-down via the signaling protocol. Sure, it says the connection should be torn down. It does not say anything at all about whether a client should automatically attempt to create a new session or not. I don't think we should specify that sort of behavior one way or another. It does not seem to affect interoperability in any way. > > > > > > > We need text describing how and when an MSRP session > > transitions to a > > > new connection (or alternatively, someone can point me to > > the existing > > > text ;)) > > > > > > > Why? It is not our lot to define user experience, only to define > > protocol behavior. Different implementers may have entirely > > different > > requirements here. We assume that some implementers will attempt to > > auto-resume sessions. > > What do you mean by auto-resume? I am not talking about user experience here. I believe it is protocol behavior to describe what happens when a SEND times out, or a 5xx is received. Currently the behavior is that a client MAY retransmit, then quits the session. If the client may also reconnect and resend, then that needs to be included as well. By auto-resume, I mean the idea that an endpoint might decide to go through the entire SDP handshake of creating a _new_ session (that is only connected with the old session in the user's head), and might attempt to resubmit any IMs that it had sent on the prior session for which it had not gotten a successful response. These would be new transactions, only coincidentally related to the failed transactions. Again, I think some implementors might choose to do this, but we should no more recommend or forbid this than we should tell implementers what color to make their buttons. > > > >> Relays shutting down gracefully, and timeouts on messages > > are simply > > >> ways for the application to learn what it needs to > > achieve its ends. > > >> Without some help, the application can't do this. > > > > > > > > > Naturally, some help is also provided by the reliable > > connection the > > > MSRP runs on top of. > > > > > > > Certainly this is true for some cases. But it cannot guarantee to me > > that in the case where I send a message and get no response, > > that I know > > that the opposite peer did not receive it. > > True. But it can give you a certain amount of more confidence that if a SEND times out, gets a 5xx, a retransmission will likely not give a better result, as opposed to if we were running MSRP over an unreliable transport. Yes, this is true. THe discussion has not been so much about retrying a message on a particular session, as attempting to start a new session when the client thinks an old session has gone bad. > > Regards, > Aki > > > >>> 2) Isn't this identical to a proxy server forwarding a > > MESSAGE (via > > >>> TCP) and then shutting down? > > >> > > >> > > >> SIP errs on the side of sending duplicates, and depends on the > > >> recipient to recognize and discard them. Doing the same in MSRP is > > >> the 4th choice in the vote. > > > > > > > > > Right. I guess the difference in MSRP is that a TR-ID is > > only unique > > > within a connection. Does it need to be? Could option#4 > > simply be to > > > make TR-ID globally unique? > > > > That is what I had in mind _if_ we chose to pursue option 4. > > But it is > > more complex than just that--we would have to worry about how long a > > receivor had to remember what TR-IDs it had seen in the past. > > > > > > > >>> I thought this is what we wanted to avoid with MSRP. If a relay > > >>> also processes the SEND (i.e., receives it in entirety before > > >>> forwarding it along on another connection), this bases a > > big burden > > >>> on the relay when the SEND contains a 5GB movie. > > >> > > >> > > >> A relay clearly does "process" a SEND, but I don't think > > we have made > > >> any require that it receive the whole thing before > > forwarding it on. > > >> If that is what you mean we wanted to avoid, then I think we have. > > >> > > >>> Why can't a relay simply peek at the first few bytes of message, > > >>> see if it is not a BIND or VISIT, and forward it > > byte-by-byte over > > >>> to the associated TCP connection. If there is trouble upstream, > > >>> simply mirror that trouble downstream. > > >> > > >> > > >> It can. It can also know that it is in the midst of forwarding a > > >> message. If it wants to shutdown before transmitting the > > last byte of > > >> the message, it can send an error response indicating > > this is what > > >> happened. > > > > > > > > > Except that an MSRP client probably isn't expecting a > > response to a > > > request it is still in the process of sending? > > > > We already have the ability for the peer endpoint to > > interrupt a message > > with an early response. It does clobber framing for the > > connection, and > > therefore requires the peer to also close the connection. > > I didn't see this spelled out anywhere in the draft. > > Regards, > Aki > > > > > > >>> This way, there are never messages in-transit over relay(s) (with > > >>> the exception of a VISIT, which is always processed by a > > relay, but > > >>> can also be forwarded to another target). > > >> > > >> > > >> I don't see why this means there aren't messages in-transit. > > > > > > > > > You're right. The problem does not go away. Even though > > there might be > > > fewer states the system could be in, the relay could still > > shut down > > > when the request is pending - and the problem would remain. > > > > > > Basically, the reason I'm raising these questions is that > > at least for > > > the non-relay case, I would like things to be as simple as > > in IRC. That > > > is, to send a message, you write it to a buffer and flush > > it. Granted, > > > the presence of relays will make things a bit more > > complicated, but > > > still we should avoid adding complexity unless it's > > absolutely necessary. > > > > > > Regards, > > > Aki > > > > > >> Paul > > >> > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 11:15:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05940 for ; Fri, 17 Oct 2003 11:15:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWK1-0001ip-5v for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 11:15:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HFFL0V006613 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 11:15:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWK1-0001gX-01 for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 11:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05890; Fri, 17 Oct 2003 11:15:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWJw-0004JR-00; Fri, 17 Oct 2003 11:15:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAWJw-0004JO-00; Fri, 17 Oct 2003 11:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWJj-0001aB-6d; Fri, 17 Oct 2003 11:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWJR-0001ZU-U5 for simple@optimus.ietf.org; Fri, 17 Oct 2003 11:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05858 for ; Fri, 17 Oct 2003 11:14:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWJR-0004Iq-00 for simple@ietf.org; Fri, 17 Oct 2003 11:14:45 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAWJQ-0004In-00 for simple@ietf.org; Fri, 17 Oct 2003 11:14:44 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HFEHeY075263; Fri, 17 Oct 2003 10:14:28 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F90073E.709@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 10:14:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: [...] > Is this acceptable? A lot of the discussion so far has made the assumption that an MSRP client would reconnect and resend if there is a timeout, a 5xx, or the connection to the relay closes. That isn't the defined behavior, it actually goes against the defined behavior. > > Bullet 5, Ch 7.4.3: > > If the endpoint receives 5xx responses more than some threshold > number of times in a row, it SHOULD assume the session has > failed, and initiate tear-down via the signaling protocol. Sure, it says the connection should be torn down. It does not say anything at all about whether a client should automatically attempt to create a new session or not. I don't think we should specify that sort of behavior one way or another. It does not seem to affect interoperability in any way. > > > > > > > We need text describing how and when an MSRP session > > transitions to a > > > new connection (or alternatively, someone can point me to > > the existing > > > text ;)) > > > > > > > Why? It is not our lot to define user experience, only to define > > protocol behavior. Different implementers may have entirely > > different > > requirements here. We assume that some implementers will attempt to > > auto-resume sessions. > > What do you mean by auto-resume? I am not talking about user experience here. I believe it is protocol behavior to describe what happens when a SEND times out, or a 5xx is received. Currently the behavior is that a client MAY retransmit, then quits the session. If the client may also reconnect and resend, then that needs to be included as well. By auto-resume, I mean the idea that an endpoint might decide to go through the entire SDP handshake of creating a _new_ session (that is only connected with the old session in the user's head), and might attempt to resubmit any IMs that it had sent on the prior session for which it had not gotten a successful response. These would be new transactions, only coincidentally related to the failed transactions. Again, I think some implementors might choose to do this, but we should no more recommend or forbid this than we should tell implementers what color to make their buttons. > > > >> Relays shutting down gracefully, and timeouts on messages > > are simply > > >> ways for the application to learn what it needs to > > achieve its ends. > > >> Without some help, the application can't do this. > > > > > > > > > Naturally, some help is also provided by the reliable > > connection the > > > MSRP runs on top of. > > > > > > > Certainly this is true for some cases. But it cannot guarantee to me > > that in the case where I send a message and get no response, > > that I know > > that the opposite peer did not receive it. > > True. But it can give you a certain amount of more confidence that if a SEND times out, gets a 5xx, a retransmission will likely not give a better result, as opposed to if we were running MSRP over an unreliable transport. Yes, this is true. THe discussion has not been so much about retrying a message on a particular session, as attempting to start a new session when the client thinks an old session has gone bad. > > Regards, > Aki > > > >>> 2) Isn't this identical to a proxy server forwarding a > > MESSAGE (via > > >>> TCP) and then shutting down? > > >> > > >> > > >> SIP errs on the side of sending duplicates, and depends on the > > >> recipient to recognize and discard them. Doing the same in MSRP is > > >> the 4th choice in the vote. > > > > > > > > > Right. I guess the difference in MSRP is that a TR-ID is > > only unique > > > within a connection. Does it need to be? Could option#4 > > simply be to > > > make TR-ID globally unique? > > > > That is what I had in mind _if_ we chose to pursue option 4. > > But it is > > more complex than just that--we would have to worry about how long a > > receivor had to remember what TR-IDs it had seen in the past. > > > > > > > >>> I thought this is what we wanted to avoid with MSRP. If a relay > > >>> also processes the SEND (i.e., receives it in entirety before > > >>> forwarding it along on another connection), this bases a > > big burden > > >>> on the relay when the SEND contains a 5GB movie. > > >> > > >> > > >> A relay clearly does "process" a SEND, but I don't think > > we have made > > >> any require that it receive the whole thing before > > forwarding it on. > > >> If that is what you mean we wanted to avoid, then I think we have. > > >> > > >>> Why can't a relay simply peek at the first few bytes of message, > > >>> see if it is not a BIND or VISIT, and forward it > > byte-by-byte over > > >>> to the associated TCP connection. If there is trouble upstream, > > >>> simply mirror that trouble downstream. > > >> > > >> > > >> It can. It can also know that it is in the midst of forwarding a > > >> message. If it wants to shutdown before transmitting the > > last byte of > > >> the message, it can send an error response indicating > > this is what > > >> happened. > > > > > > > > > Except that an MSRP client probably isn't expecting a > > response to a > > > request it is still in the process of sending? > > > > We already have the ability for the peer endpoint to > > interrupt a message > > with an early response. It does clobber framing for the > > connection, and > > therefore requires the peer to also close the connection. > > I didn't see this spelled out anywhere in the draft. > > Regards, > Aki > > > > > > >>> This way, there are never messages in-transit over relay(s) (with > > >>> the exception of a VISIT, which is always processed by a > > relay, but > > >>> can also be forwarded to another target). > > >> > > >> > > >> I don't see why this means there aren't messages in-transit. > > > > > > > > > You're right. The problem does not go away. Even though > > there might be > > > fewer states the system could be in, the relay could still > > shut down > > > when the request is pending - and the problem would remain. > > > > > > Basically, the reason I'm raising these questions is that > > at least for > > > the non-relay case, I would like things to be as simple as > > in IRC. That > > > is, to send a message, you write it to a buffer and flush > > it. Granted, > > > the presence of relays will make things a bit more > > complicated, but > > > still we should avoid adding complexity unless it's > > absolutely necessary. > > > > > > Regards, > > > Aki > > > > > >> Paul > > >> > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 11:35:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06959; Fri, 17 Oct 2003 11:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWdD-0004ec-00; Fri, 17 Oct 2003 11:35:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAWdD-0004eZ-00; Fri, 17 Oct 2003 11:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWd3-0002IC-NX; Fri, 17 Oct 2003 11:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWcU-0002GY-IW for simple@optimus.ietf.org; Fri, 17 Oct 2003 11:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06837 for ; Fri, 17 Oct 2003 11:34:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWcO-0004ch-00 for simple@ietf.org; Fri, 17 Oct 2003 11:34:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAWcN-0004ca-00 for simple@ietf.org; Fri, 17 Oct 2003 11:34:20 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HFYJX20926 for ; Fri, 17 Oct 2003 18:34:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 Oct 2003 18:34:18 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 18:34:18 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id SAA21496 for ; Fri, 17 Oct 2003 18:34:19 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KNZ4mS006800 for ; Tue, 21 Oct 2003 02:35:04 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KNZ4mQ006799; Tue, 21 Oct 2003 02:35:04 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 17 Oct 2003 15:34:18.0636 (UTC) FILETIME=[211A04C0:01C394C4] Subject: [Simple] MSRP, SDP and CPIM Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 02:35:04 +0300 Hi, First, I've a problem with SDP usage by MSRP. The format parameters on SDP media line should be tokens, and "/" is not allowed within an SDP token. The token issue was discussed in MMUSIC wg, and the wg consensus was to keep definition of token as is (and fix the comment in sdp-new). So, the top-level media types should be put into an SDP attribute just like accept-wrapped-types. Example: m=message 9999 msrp/tcp * a=msrp-accept:message/cpim text/plain, text/html Alternatively, we could mandate that the MSRP content should always be Message/CPIM. The message/cpim itself mandates one header, Requires. So, instead of m=message 9999 msrp/tcp message/cpim text/plain text/html we would have something like this m=message 9999 msrp/tcp cpim a=msrp-accept: text/plain, text/html So, what would change at MSRP level? Currently we can have an MSRP message like this: MSRP xx SEND TR-ID: 123 Content-Type: text/plain Hi, I'm Alice! Instead of that, we could have a CPIM message with implied MIME type message/cpim (so, no Content-Type header in MSRP). Here we have CPIM message without any CPIM headers: MSRP xx SEND TR-ID: 123 Content-Type: text/plain Hi, I'm Alice! So, we pay two extra pairs of CR-LF for CPIM support. Sender can always include CPIM headers, like From and To, MSRP xx SEND TR-ID: 123 From: Alice To: Bob Content-Type: text/plain Hi, I'm Alice! but the recipient can safely ignore them. The only exception is Requires header. In order to properly process Requires, we need 420 Not Supported, too. Then it might be possible to extend MSRP using CPIM Requires header. Perhaps the supported or required extensions could be indicated as SDP attributes, too. What about signed CPIM messages? The could be sent inside another one MSRP xx SEND TR-ID: 123 My-Own-CPIM-Header: please see secured content Content-Type: multipart/signed; boundary=boundary; micalg=sha1; protocol=application/pkcs7-signature --boundary Content-Type: message/cpim From: Alice To: Bob Content-Type: text/plain Hi, I'm Alice! --boundary Content-Type: application/pkcs7-signature (lots-of-binary-signature-here) --boundary-- The real issue of CPIM is that it is just a wrapper around a MIME object. This is not a problem with most SIP implementations, as they already support MIME, but there may be some use of MSRP outside SIP? we could reuse CPIM header structure (quoting, line ending, etc) in MSRP, if we choose to always have a message/cpim wrapper. I don't mean that MSRP headers would be part of CPIM message, but that they reuse the Header ABNF from CPIM. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 11:35:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07028 for ; Fri, 17 Oct 2003 11:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWdF-0002MP-Hf for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 11:35:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HFZDgX009072 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 11:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWdF-0002MF-Ed for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 11:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06959; Fri, 17 Oct 2003 11:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWdD-0004ec-00; Fri, 17 Oct 2003 11:35:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAWdD-0004eZ-00; Fri, 17 Oct 2003 11:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWd3-0002IC-NX; Fri, 17 Oct 2003 11:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWcU-0002GY-IW for simple@optimus.ietf.org; Fri, 17 Oct 2003 11:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06837 for ; Fri, 17 Oct 2003 11:34:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWcO-0004ch-00 for simple@ietf.org; Fri, 17 Oct 2003 11:34:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAWcN-0004ca-00 for simple@ietf.org; Fri, 17 Oct 2003 11:34:20 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HFYJX20926 for ; Fri, 17 Oct 2003 18:34:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 Oct 2003 18:34:18 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 18:34:18 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id SAA21496 for ; Fri, 17 Oct 2003 18:34:19 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KNZ4mS006800 for ; Tue, 21 Oct 2003 02:35:04 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KNZ4mQ006799; Tue, 21 Oct 2003 02:35:04 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 17 Oct 2003 15:34:18.0636 (UTC) FILETIME=[211A04C0:01C394C4] Subject: [Simple] MSRP, SDP and CPIM Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 02:35:04 +0300 Hi, First, I've a problem with SDP usage by MSRP. The format parameters on SDP media line should be tokens, and "/" is not allowed within an SDP token. The token issue was discussed in MMUSIC wg, and the wg consensus was to keep definition of token as is (and fix the comment in sdp-new). So, the top-level media types should be put into an SDP attribute just like accept-wrapped-types. Example: m=message 9999 msrp/tcp * a=msrp-accept:message/cpim text/plain, text/html Alternatively, we could mandate that the MSRP content should always be Message/CPIM. The message/cpim itself mandates one header, Requires. So, instead of m=message 9999 msrp/tcp message/cpim text/plain text/html we would have something like this m=message 9999 msrp/tcp cpim a=msrp-accept: text/plain, text/html So, what would change at MSRP level? Currently we can have an MSRP message like this: MSRP xx SEND TR-ID: 123 Content-Type: text/plain Hi, I'm Alice! Instead of that, we could have a CPIM message with implied MIME type message/cpim (so, no Content-Type header in MSRP). Here we have CPIM message without any CPIM headers: MSRP xx SEND TR-ID: 123 Content-Type: text/plain Hi, I'm Alice! So, we pay two extra pairs of CR-LF for CPIM support. Sender can always include CPIM headers, like From and To, MSRP xx SEND TR-ID: 123 From: Alice To: Bob Content-Type: text/plain Hi, I'm Alice! but the recipient can safely ignore them. The only exception is Requires header. In order to properly process Requires, we need 420 Not Supported, too. Then it might be possible to extend MSRP using CPIM Requires header. Perhaps the supported or required extensions could be indicated as SDP attributes, too. What about signed CPIM messages? The could be sent inside another one MSRP xx SEND TR-ID: 123 My-Own-CPIM-Header: please see secured content Content-Type: multipart/signed; boundary=boundary; micalg=sha1; protocol=application/pkcs7-signature --boundary Content-Type: message/cpim From: Alice To: Bob Content-Type: text/plain Hi, I'm Alice! --boundary Content-Type: application/pkcs7-signature (lots-of-binary-signature-here) --boundary-- The real issue of CPIM is that it is just a wrapper around a MIME object. This is not a problem with most SIP implementations, as they already support MIME, but there may be some use of MSRP outside SIP? we could reuse CPIM header structure (quoting, line ending, etc) in MSRP, if we choose to always have a message/cpim wrapper. I don't mean that MSRP headers would be part of CPIM message, but that they reuse the Header ABNF from CPIM. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 11:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08054; Fri, 17 Oct 2003 11:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWyL-0003oS-0M; Fri, 17 Oct 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWxS-0003l4-5V for simple@optimus.ietf.org; Fri, 17 Oct 2003 11:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08022 for ; Fri, 17 Oct 2003 11:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWxQ-0004yp-00 for simple@ietf.org; Fri, 17 Oct 2003 11:56:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AAWxQ-0004yV-00 for simple@ietf.org; Fri, 17 Oct 2003 11:56:04 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9HFtUFQ016496; Fri, 17 Oct 2003 11:55:30 -0400 (EDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADF52020; Fri, 17 Oct 2003 11:55:29 -0400 (EDT) Message-ID: <3F9010F1.3040202@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: aki.niemi@nokia.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> <3F90073E.709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 11:55:29 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > aki.niemi@nokia.com wrote: > > [...] > >> Is this acceptable? A lot of the discussion so far has made the >> assumption that an MSRP client would reconnect and resend if there is >> a timeout, a 5xx, or the connection to the relay closes. That isn't >> the defined behavior, it actually goes against the defined behavior. >> >> Bullet 5, Ch 7.4.3: >> >> If the endpoint receives 5xx responses more than some threshold >> number of times in a row, it SHOULD assume the session has >> failed, and initiate tear-down via the signaling protocol. > > > Sure, it says the connection should be torn down. It does not say > anything at all about whether a client should automatically attempt to > create a new session or not. I don't think we should specify that sort > of behavior one way or another. It does not seem to affect > interoperability in any way. ... > By auto-resume, I mean the idea that an endpoint might decide to go > through the entire SDP handshake of creating a _new_ session (that is > only connected with the old session in the user's head), and might > attempt to resubmit any IMs that it had sent on the prior session for > which it had not gotten a successful response. These would be new > transactions, only coincidentally related to the failed transactions. > > Again, I think some implementors might choose to do this, but we should > no more recommend or forbid this than we should tell implementers what > color to make their buttons. I don't think we should recommend or forbid this. But I think it may be necessary to say something about how you should do it, if you want to, so that we get proper interoperation. This is very closely related to the process of transferring a call with an MSRP session. The transfer may appear to one endpoint as either an in-dialog refer, an invite/replaces, or a reinvite. In any of these cases a new MSRP session will be established that will eventually replace the old one. But there is some ambiguity about how to handle messages during the transfer. This has largely been ignored for voice, where arguably it only results in a small glitch that doesn't have significant consequences. But in the case of MSRP it can result in the duplication, loss, or misdirection of whole messages, which is more significant than a glitch. This is probably the wrong document to address this - it may require a document of its own. But getting it right may end up needing help from MSRP. Related point: Aki or somebody previously pointed out the passage above about retrying 5xx responses. If a relay has gone down, or is trying to shut down, this retrying behavior is counterproductive. We ought to ban retries at least after receiving the code indicating the relay wants to shut down. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 11:58:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08085 for ; Fri, 17 Oct 2003 11:57:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWyv-0003ve-0y for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 11:57:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HFvaAQ015096 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 11:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWyu-0003vP-SS for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 11:57:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08054; Fri, 17 Oct 2003 11:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWyL-0003oS-0M; Fri, 17 Oct 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWxS-0003l4-5V for simple@optimus.ietf.org; Fri, 17 Oct 2003 11:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08022 for ; Fri, 17 Oct 2003 11:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWxQ-0004yp-00 for simple@ietf.org; Fri, 17 Oct 2003 11:56:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AAWxQ-0004yV-00 for simple@ietf.org; Fri, 17 Oct 2003 11:56:04 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9HFtUFQ016496; Fri, 17 Oct 2003 11:55:30 -0400 (EDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADF52020; Fri, 17 Oct 2003 11:55:29 -0400 (EDT) Message-ID: <3F9010F1.3040202@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: aki.niemi@nokia.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59276@esebe013.ntc.nokia.com> <3F90073E.709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 11:55:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > aki.niemi@nokia.com wrote: > > [...] > >> Is this acceptable? A lot of the discussion so far has made the >> assumption that an MSRP client would reconnect and resend if there is >> a timeout, a 5xx, or the connection to the relay closes. That isn't >> the defined behavior, it actually goes against the defined behavior. >> >> Bullet 5, Ch 7.4.3: >> >> If the endpoint receives 5xx responses more than some threshold >> number of times in a row, it SHOULD assume the session has >> failed, and initiate tear-down via the signaling protocol. > > > Sure, it says the connection should be torn down. It does not say > anything at all about whether a client should automatically attempt to > create a new session or not. I don't think we should specify that sort > of behavior one way or another. It does not seem to affect > interoperability in any way. ... > By auto-resume, I mean the idea that an endpoint might decide to go > through the entire SDP handshake of creating a _new_ session (that is > only connected with the old session in the user's head), and might > attempt to resubmit any IMs that it had sent on the prior session for > which it had not gotten a successful response. These would be new > transactions, only coincidentally related to the failed transactions. > > Again, I think some implementors might choose to do this, but we should > no more recommend or forbid this than we should tell implementers what > color to make their buttons. I don't think we should recommend or forbid this. But I think it may be necessary to say something about how you should do it, if you want to, so that we get proper interoperation. This is very closely related to the process of transferring a call with an MSRP session. The transfer may appear to one endpoint as either an in-dialog refer, an invite/replaces, or a reinvite. In any of these cases a new MSRP session will be established that will eventually replace the old one. But there is some ambiguity about how to handle messages during the transfer. This has largely been ignored for voice, where arguably it only results in a small glitch that doesn't have significant consequences. But in the case of MSRP it can result in the duplication, loss, or misdirection of whole messages, which is more significant than a glitch. This is probably the wrong document to address this - it may require a document of its own. But getting it right may end up needing help from MSRP. Related point: Aki or somebody previously pointed out the passage above about retrying 5xx responses. If a relay has gone down, or is trying to shut down, this retrying behavior is counterproductive. We ought to ban retries at least after receiving the code indicating the relay wants to shut down. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:30:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11702; Fri, 17 Oct 2003 13:30:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYRL-000624-00; Fri, 17 Oct 2003 13:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYRK-000621-00; Fri, 17 Oct 2003 13:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYRK-0000G4-8Y; Fri, 17 Oct 2003 13:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYQl-0000EL-62 for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11643 for ; Fri, 17 Oct 2003 13:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYPs-00060H-00 for simple@ietf.org; Fri, 17 Oct 2003 13:29:32 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYPr-0005zz-00 for simple@ietf.org; Fri, 17 Oct 2003 13:29:31 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHTCeY086380; Fri, 17 Oct 2003 12:29:23 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F9026DB.40202@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments - specific issues References: <3F8EBF76.9030901@nokia.com> In-Reply-To: <3F8EBF76.9030901@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:28:59 -0500 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > I tried to make a truly thorough read of MSRP, and provide some comments > on it. I didn't have time to go through the examples, though. Maybe next > time ;) > > Here are first some specific issues about the draft. Mainly some > corrections and clarifications. I will send a separate email with all of > the nits I found in the draft. > > I will probably also send a couple of other emails each with a bit > bigger issue I felt might be important to address separately. > > Regards, > Aki > > --- > > - Chapter 1, 1st paragraph, last sentence: Should probably add that in > page-mode, there is usually only an imaginative session, but messages > are not related in any other way. Versus in session mode where there is > a concrete relationship between messages. OK. > > - Ch 2., 1st para., last sentence is confusing. No need to couple MSRP > and SIP like that. Hmm. The point was to illustrate that this was different than SIP, and that MSRP messages do not follow the SIP path. Obviously this is meaningless if you are not using sip at all--but I wanted to include this to contrast MSRP from previous proposals (and page mode) that _did_ traverse the SIP proxy fabric. I will attempt to re-word. > > - Ch 6.2, 3rd para., definition of the "both" direction is somehow > confusing. It uses three names (host, visitor, answerer) for two > entities. Need to make names consistent. > Hmm. The third paragraph is "The direction attribute is included in an SDP a-line, with a value taking the following syntax:" I assume this is the paragraph you meant. Actually, there are 4 names: Offerer, answerer, host, visitor. Offerer and answerer are specific to who sends the SDP offer. Host and visitor are specific to who hosts the MSRP session. The offerer/answerer and host/visitor choices are not bound together, that is, the offerer could end up the visitor, and the answerer could end up the host. > - Ch 7, 2nd para.: Doesn't this spec only define use of TCP? Why this > wording? I am clarifying elsewhere that this draft specifies a TCP binding, and other drafts could specify other bindings. However, any such bindings must use reliable transports. I can accept that it is not this draft's job to say what kind of transports could be used. If someone tries to do a UDP binding, we can worry about it then. > > - Ch 7.1.2, last para., When MSRP URL is communicated outside SDP, why > would protocol need to be communicated, if the default is TCP, and MSRPS > requires TLS? Wouldn't DNS SRV be enough here? Because we may have future bindings to other protocols. (There is already interest in an SCTP binding.) > > - Ch 7.2, what is the extensibility model of MSRP? Should there be: > > Method = SEND / BIND / VISIT / other-method > other-method = token Good point. > > - Ch 7.2, would be nice to have the ABNF definitions collected into one > place instead of spread across chapters. I have heard opinions either way. I think your comment tips the balance in favor of collecting it all in one place. > > - Ch 7.3, 3rd para., Why not make TR-ID global uniqueness be a MUST? > That would help detect duplicate messages in case a relay crashes while > SEND is pending, and the client resends the message. I don't want to do this unless we have concensus to go all the way to build a cross-session duplicate surpression mechanism--which will require more work than just having unique IDs. Otherwise, it just creates a calculation burden of having to create a guid for each message. > > - Ch 7.4.1, bullet 1., Should clarify that the temporary, hard-to-guess > property applies specifically to the "resource" part Why does that matter. If someone comes up with some weird scheme to have a different host part in each, and makes them all resolve correctly, why do we care? > > - Ch 7.4.1, bullet 4, What are the "circumstances" that would warrant > the different timeout? Last sentence makes no sense to me. > One possibility would be known network conditions that cause TCP connections to typically take longer than average. I will put that in as an example, But I don't think it is up to this draft to enumerate circumstances that might call for a different value. I am glad you brought it up though, as in the process of following up, I noticed the BNF for this is wrong (the timeout option is on "passive" rather than "both".) > - Ch 7.4.1, 2nd set of bullets, paragraph after 3rd bullet, 2nd > sentence: This sentence is really hard to parse. Suggest splitting it up > to simplify. OK. That one made me dizzy when I wrote it :-) > > - Ch 7.4.3, 1st set of bullets, bullet 6, why is this needed (as opposed > to just sending a 400)? The endpoints have already negotiated the set of > allowed MIME types. Why add this dynamic removal, and is there a similar > way to dynamicly add media types in a session? The SDP allows one to negotiate a "try anything" approach. This was to avoid insanely large format lists for rich endpoints. > > - Ch 7.4.3, 2nd set of bullets, 3rd bullet, same as above. > > - Ch 7.5.4, 3rd bullet, relay is supposed to send 500, but 500 is only > defined as response for SEND. OK > > - Ch 7.6, 1st para., it states that MSRP digest doesn't support the > realm. Why is that? In HTTP digest, realm is a textual string intended > for the user to consume and to help select the correct username/password. > I seem to recall having a discussion about this at one of the meetings where the consensus was that we did not need realm. I must admit that I cannot remember the reasoning. I will have to dig to see if I can find something. > - Ch 7.9.3, says "...usually in response to a digest authentication > challenge." When else would this happen? > I think we had at one point assumed that the client could attempt to preemptively load CAuth with a previously seen nonce. Since we have not specififed that behavior, I will adjust the wording. > - Ch 7.9.3, ABNF and definition for request-digest, SHA1 produces as > output 160 bits (MD5 is 128bits), so this should be <"> 40LHEX <">. OK > > - Ch 7.9.4, text claims extensibility of authentication mechanism, but > syntax only allows for "Digest". > > We decided at the interim meeting not to include extensibility. I will adjust the wording that indicates otherwise. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:31:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11816 for ; Fri, 17 Oct 2003 13:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYRP-0000IG-Vc for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:31:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHV7qX001122 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYRP-0000I1-S6 for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:31:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11702; Fri, 17 Oct 2003 13:30:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYRL-000624-00; Fri, 17 Oct 2003 13:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYRK-000621-00; Fri, 17 Oct 2003 13:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYRK-0000G4-8Y; Fri, 17 Oct 2003 13:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYQl-0000EL-62 for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11643 for ; Fri, 17 Oct 2003 13:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYPs-00060H-00 for simple@ietf.org; Fri, 17 Oct 2003 13:29:32 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYPr-0005zz-00 for simple@ietf.org; Fri, 17 Oct 2003 13:29:31 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHTCeY086380; Fri, 17 Oct 2003 12:29:23 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F9026DB.40202@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments - specific issues References: <3F8EBF76.9030901@nokia.com> In-Reply-To: <3F8EBF76.9030901@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:28:59 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > I tried to make a truly thorough read of MSRP, and provide some comments > on it. I didn't have time to go through the examples, though. Maybe next > time ;) > > Here are first some specific issues about the draft. Mainly some > corrections and clarifications. I will send a separate email with all of > the nits I found in the draft. > > I will probably also send a couple of other emails each with a bit > bigger issue I felt might be important to address separately. > > Regards, > Aki > > --- > > - Chapter 1, 1st paragraph, last sentence: Should probably add that in > page-mode, there is usually only an imaginative session, but messages > are not related in any other way. Versus in session mode where there is > a concrete relationship between messages. OK. > > - Ch 2., 1st para., last sentence is confusing. No need to couple MSRP > and SIP like that. Hmm. The point was to illustrate that this was different than SIP, and that MSRP messages do not follow the SIP path. Obviously this is meaningless if you are not using sip at all--but I wanted to include this to contrast MSRP from previous proposals (and page mode) that _did_ traverse the SIP proxy fabric. I will attempt to re-word. > > - Ch 6.2, 3rd para., definition of the "both" direction is somehow > confusing. It uses three names (host, visitor, answerer) for two > entities. Need to make names consistent. > Hmm. The third paragraph is "The direction attribute is included in an SDP a-line, with a value taking the following syntax:" I assume this is the paragraph you meant. Actually, there are 4 names: Offerer, answerer, host, visitor. Offerer and answerer are specific to who sends the SDP offer. Host and visitor are specific to who hosts the MSRP session. The offerer/answerer and host/visitor choices are not bound together, that is, the offerer could end up the visitor, and the answerer could end up the host. > - Ch 7, 2nd para.: Doesn't this spec only define use of TCP? Why this > wording? I am clarifying elsewhere that this draft specifies a TCP binding, and other drafts could specify other bindings. However, any such bindings must use reliable transports. I can accept that it is not this draft's job to say what kind of transports could be used. If someone tries to do a UDP binding, we can worry about it then. > > - Ch 7.1.2, last para., When MSRP URL is communicated outside SDP, why > would protocol need to be communicated, if the default is TCP, and MSRPS > requires TLS? Wouldn't DNS SRV be enough here? Because we may have future bindings to other protocols. (There is already interest in an SCTP binding.) > > - Ch 7.2, what is the extensibility model of MSRP? Should there be: > > Method = SEND / BIND / VISIT / other-method > other-method = token Good point. > > - Ch 7.2, would be nice to have the ABNF definitions collected into one > place instead of spread across chapters. I have heard opinions either way. I think your comment tips the balance in favor of collecting it all in one place. > > - Ch 7.3, 3rd para., Why not make TR-ID global uniqueness be a MUST? > That would help detect duplicate messages in case a relay crashes while > SEND is pending, and the client resends the message. I don't want to do this unless we have concensus to go all the way to build a cross-session duplicate surpression mechanism--which will require more work than just having unique IDs. Otherwise, it just creates a calculation burden of having to create a guid for each message. > > - Ch 7.4.1, bullet 1., Should clarify that the temporary, hard-to-guess > property applies specifically to the "resource" part Why does that matter. If someone comes up with some weird scheme to have a different host part in each, and makes them all resolve correctly, why do we care? > > - Ch 7.4.1, bullet 4, What are the "circumstances" that would warrant > the different timeout? Last sentence makes no sense to me. > One possibility would be known network conditions that cause TCP connections to typically take longer than average. I will put that in as an example, But I don't think it is up to this draft to enumerate circumstances that might call for a different value. I am glad you brought it up though, as in the process of following up, I noticed the BNF for this is wrong (the timeout option is on "passive" rather than "both".) > - Ch 7.4.1, 2nd set of bullets, paragraph after 3rd bullet, 2nd > sentence: This sentence is really hard to parse. Suggest splitting it up > to simplify. OK. That one made me dizzy when I wrote it :-) > > - Ch 7.4.3, 1st set of bullets, bullet 6, why is this needed (as opposed > to just sending a 400)? The endpoints have already negotiated the set of > allowed MIME types. Why add this dynamic removal, and is there a similar > way to dynamicly add media types in a session? The SDP allows one to negotiate a "try anything" approach. This was to avoid insanely large format lists for rich endpoints. > > - Ch 7.4.3, 2nd set of bullets, 3rd bullet, same as above. > > - Ch 7.5.4, 3rd bullet, relay is supposed to send 500, but 500 is only > defined as response for SEND. OK > > - Ch 7.6, 1st para., it states that MSRP digest doesn't support the > realm. Why is that? In HTTP digest, realm is a textual string intended > for the user to consume and to help select the correct username/password. > I seem to recall having a discussion about this at one of the meetings where the consensus was that we did not need realm. I must admit that I cannot remember the reasoning. I will have to dig to see if I can find something. > - Ch 7.9.3, says "...usually in response to a digest authentication > challenge." When else would this happen? > I think we had at one point assumed that the client could attempt to preemptively load CAuth with a previously seen nonce. Since we have not specififed that behavior, I will adjust the wording. > - Ch 7.9.3, ABNF and definition for request-digest, SHA1 produces as > output 160 bits (MD5 is 128bits), so this should be <"> 40LHEX <">. OK > > - Ch 7.9.4, text claims extensibility of authentication mechanism, but > syntax only allows for "Digest". > > We decided at the interim meeting not to include extensibility. I will adjust the wording that indicates otherwise. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:34:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11981; Fri, 17 Oct 2003 13:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYUK-00066v-00; Fri, 17 Oct 2003 13:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYUK-00066s-00; Fri, 17 Oct 2003 13:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYUD-0000Pj-2k; Fri, 17 Oct 2003 13:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYTR-0000Me-Dq for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11963 for ; Fri, 17 Oct 2003 13:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYTP-00066K-00 for simple@ietf.org; Fri, 17 Oct 2003 13:33:11 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYTO-00066E-00 for simple@ietf.org; Fri, 17 Oct 2003 13:33:10 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHX9eY086721; Fri, 17 Oct 2003 12:33:09 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F9027C8.2080606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments - nits References: <3F8EBF90.9050703@nokia.com> In-Reply-To: <3F8EBF90.9050703@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:32:56 -0500 Content-Transfer-Encoding: 7bit Thanks Aki. I will fix these. Aki Niemi wrote: > Hi, > > Here are some nits found for MSRP. > > Regards, > Aki > > --- > > - Title needs to be spelled out. Maybe talk about MSRP there, too. > > - Abstract: need to spell out SDP and SIP. > > - Chapter 1, 1st paragraph, last sentence: page-mode -> Page-mode. > > - Ch 5.1, last para., first sentence: "...purpose in that the..." > ^^^^ -> they > > - Ch 5.2, 1st para., 1st sentence: "...long messages on a..." > ^^^ -> in > > - Ch 6.1, 3rd p., 2nd s.: "...indicates that the endpoint is may be..." > remove "is" > > - Ch 6.2, 3rd p., ABNF doesn't allow "timeout" in "both", only in > "passive". > > - Ch 6.3, 1st p., 3rd s., "Occasionally and endpoint..." > ^^^ -> an > > - Ch 6.3, 3rd p., last s., "...both as a root body, or..." > ^^^ -> and > > - Ch 6.4, 1st p., 2nd s., "...that is, contains a direction..." > ^ -> insert "it" > > - Ch 6.4, 2nd p., last s., "meeting" -> "meaning" > > - Ch 6.5, 2nd p., 1st s., remove ";" from URL > > - Ch 7.2, some of the ABNF goes over 72 char lines. > > - Ch 7.4.1, bullet 4, remove double-quote after 3rd sentence > > - Ch 7.4.1, 2nd set of bullets, p. after bullet 3, 1st s., "...must > choose whether of act..." > ^^ -> to > > - Ch 7.4.4, 1st p., last s., "...or an a relay." > ^^ -> on > > - Ch 7.4.4, 2nd p., 4th s., "...be sent host connection..." > ^ insert "on the" > > - Ch 7.4.6, 1st p., 4ts s., "The connection hosting device..." > ^ insert "between the" > > - Ch 7.5.1, 1st p., remove extra period at the end. > > - Ch 7.5.1, 2nd p., 1st s., "...constructs session URL." > ^ the > > - Ch 7.5.1., 3rd bullet, "Expire" -> "Exp" > > - Ch 7.5.1, 2nd set of bullets, 2nd bullet, 3rd s., > "...not duplicate URL..." > ^ any > > - ..., 4th s., "...connect over a point..." > ^^^^^ port > > - Ch 7.5.1, 2nd set of bullets, 3rd bullet, delete extra "section" > > - Ch 7.5.4, 7th bullet, "...subsequent arriving on... > ^ requests > > - Ch 7.9.3, 1st p., 1st s., extra words "...endpoint to respond to > offer..." ^^^^^^^^^^ > > - Ch 10.2, 1st para., 4th line, "...to acquire session URL..." > ^ the > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12007 for ; Fri, 17 Oct 2003 13:34:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYUP-0000Ty-T1 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:34:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHYDDX001848 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYUP-0000Tj-Pl for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:34:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11981; Fri, 17 Oct 2003 13:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYUK-00066v-00; Fri, 17 Oct 2003 13:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYUK-00066s-00; Fri, 17 Oct 2003 13:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYUD-0000Pj-2k; Fri, 17 Oct 2003 13:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYTR-0000Me-Dq for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11963 for ; Fri, 17 Oct 2003 13:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYTP-00066K-00 for simple@ietf.org; Fri, 17 Oct 2003 13:33:11 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYTO-00066E-00 for simple@ietf.org; Fri, 17 Oct 2003 13:33:10 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHX9eY086721; Fri, 17 Oct 2003 12:33:09 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F9027C8.2080606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments - nits References: <3F8EBF90.9050703@nokia.com> In-Reply-To: <3F8EBF90.9050703@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:32:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Aki. I will fix these. Aki Niemi wrote: > Hi, > > Here are some nits found for MSRP. > > Regards, > Aki > > --- > > - Title needs to be spelled out. Maybe talk about MSRP there, too. > > - Abstract: need to spell out SDP and SIP. > > - Chapter 1, 1st paragraph, last sentence: page-mode -> Page-mode. > > - Ch 5.1, last para., first sentence: "...purpose in that the..." > ^^^^ -> they > > - Ch 5.2, 1st para., 1st sentence: "...long messages on a..." > ^^^ -> in > > - Ch 6.1, 3rd p., 2nd s.: "...indicates that the endpoint is may be..." > remove "is" > > - Ch 6.2, 3rd p., ABNF doesn't allow "timeout" in "both", only in > "passive". > > - Ch 6.3, 1st p., 3rd s., "Occasionally and endpoint..." > ^^^ -> an > > - Ch 6.3, 3rd p., last s., "...both as a root body, or..." > ^^^ -> and > > - Ch 6.4, 1st p., 2nd s., "...that is, contains a direction..." > ^ -> insert "it" > > - Ch 6.4, 2nd p., last s., "meeting" -> "meaning" > > - Ch 6.5, 2nd p., 1st s., remove ";" from URL > > - Ch 7.2, some of the ABNF goes over 72 char lines. > > - Ch 7.4.1, bullet 4, remove double-quote after 3rd sentence > > - Ch 7.4.1, 2nd set of bullets, p. after bullet 3, 1st s., "...must > choose whether of act..." > ^^ -> to > > - Ch 7.4.4, 1st p., last s., "...or an a relay." > ^^ -> on > > - Ch 7.4.4, 2nd p., 4th s., "...be sent host connection..." > ^ insert "on the" > > - Ch 7.4.6, 1st p., 4ts s., "The connection hosting device..." > ^ insert "between the" > > - Ch 7.5.1, 1st p., remove extra period at the end. > > - Ch 7.5.1, 2nd p., 1st s., "...constructs session URL." > ^ the > > - Ch 7.5.1., 3rd bullet, "Expire" -> "Exp" > > - Ch 7.5.1, 2nd set of bullets, 2nd bullet, 3rd s., > "...not duplicate URL..." > ^ any > > - ..., 4th s., "...connect over a point..." > ^^^^^ port > > - Ch 7.5.1, 2nd set of bullets, 3rd bullet, delete extra "section" > > - Ch 7.5.4, 7th bullet, "...subsequent arriving on... > ^ requests > > - Ch 7.9.3, 1st p., 1st s., extra words "...endpoint to respond to > offer..." ^^^^^^^^^^ > > - Ch 10.2, 1st para., 4th line, "...to acquire session URL..." > ^ the > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:36:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12216; Fri, 17 Oct 2003 13:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYXA-0006AV-00; Fri, 17 Oct 2003 13:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYXA-0006AS-00; Fri, 17 Oct 2003 13:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYX7-0000cc-J5; Fri, 17 Oct 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYW9-0000WL-Lv for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12078 for ; Fri, 17 Oct 2003 13:35:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYW7-000687-00 for simple@ietf.org; Fri, 17 Oct 2003 13:35:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYW6-00067z-00 for simple@ietf.org; Fri, 17 Oct 2003 13:35:58 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHZweY086982; Fri, 17 Oct 2003 12:35:58 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902871.30502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: <3F8EC0F4.3080608@nokia.com> In-Reply-To: <3F8EC0F4.3080608@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:35:45 -0500 Content-Transfer-Encoding: 7bit We talked about how this could be done in a couple of ways. One was by simply having the mixer remember the identity associated with each connection. The mixer could also insist that all content be wrapped in message/cpim using our extension to the SDP format list negotiation. Aki Niemi wrote: > Hi All, > > Since MSGFMT is no longer mandated (or is but only for CPIM gateways), > how would a participant know where a message is coming from in a > multiparty message session? > > Also, when using MSRP in a conferencing system, the lack of To/From > prevents sending private messages efficiently within a multiparty > session using an MSRP mixer as a "router" for them. > > So my question is this: what is the extensibility model for MSRP? For > example, would it be possible to later on add this multiparty > functionality as an extension, or would it be wise to think ahead > already now? > > The draft includes some extensibility, e.g., for authentication > algorithms, but I didn't immediately find much about adding methods and > headers, and what to do with unknown headers. > > Regards, > Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:37:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12281 for ; Fri, 17 Oct 2003 13:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYXG-0000jr-Mc for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:37:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHbA4j002698 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYXF-0000g1-Qw for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:37:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12216; Fri, 17 Oct 2003 13:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYXA-0006AV-00; Fri, 17 Oct 2003 13:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYXA-0006AS-00; Fri, 17 Oct 2003 13:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYX7-0000cc-J5; Fri, 17 Oct 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYW9-0000WL-Lv for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12078 for ; Fri, 17 Oct 2003 13:35:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYW7-000687-00 for simple@ietf.org; Fri, 17 Oct 2003 13:35:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYW6-00067z-00 for simple@ietf.org; Fri, 17 Oct 2003 13:35:58 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHZweY086982; Fri, 17 Oct 2003 12:35:58 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902871.30502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: <3F8EC0F4.3080608@nokia.com> In-Reply-To: <3F8EC0F4.3080608@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:35:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We talked about how this could be done in a couple of ways. One was by simply having the mixer remember the identity associated with each connection. The mixer could also insist that all content be wrapped in message/cpim using our extension to the SDP format list negotiation. Aki Niemi wrote: > Hi All, > > Since MSGFMT is no longer mandated (or is but only for CPIM gateways), > how would a participant know where a message is coming from in a > multiparty message session? > > Also, when using MSRP in a conferencing system, the lack of To/From > prevents sending private messages efficiently within a multiparty > session using an MSRP mixer as a "router" for them. > > So my question is this: what is the extensibility model for MSRP? For > example, would it be possible to later on add this multiparty > functionality as an extension, or would it be wise to think ahead > already now? > > The draft includes some extensibility, e.g., for authentication > algorithms, but I didn't immediately find much about adding methods and > headers, and what to do with unknown headers. > > Regards, > Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:44:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12484; Fri, 17 Oct 2003 13:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYet-0006G9-00; Fri, 17 Oct 2003 13:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYes-0006G6-00; Fri, 17 Oct 2003 13:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYes-00018i-5x; Fri, 17 Oct 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYeN-00018G-AO for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:44:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12465 for ; Fri, 17 Oct 2003 13:44:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYeL-0006Ff-00 for simple@ietf.org; Fri, 17 Oct 2003 13:44:29 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYeK-0006Fc-00 for simple@ietf.org; Fri, 17 Oct 2003 13:44:28 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHiLeY087640; Fri, 17 Oct 2003 12:44:28 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902A68.3060108@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <3F8EC115.4090305@nokia.com> In-Reply-To: <3F8EC115.4090305@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:44:08 -0500 Content-Transfer-Encoding: 7bit Based on recent discussions, I think we may need to rethink this. The point to resending was _not_ to build a reliability mechanism on top of TCP. We really wanted a mechanism to simply warn the user if we could not be sure the opposite endpoint had actually processed the message. I think we should either remove the text encouraging re-submission, or change it to re-use the same TR-ID, and add text to describe what the peer should do if it sees duplicate TR-IDs. Having a response delayed by a long request in the recipricol direction is a problem I don't think we have considered. I welcome input as to whether we think this is a real issue, and if so, how to deal with it. Aki Niemi wrote: > Hi, > > In the draft, if a SEND times out, the MSRP client is supposed to handle > this as if a 5xx was received. I.e., it will resend the message a few > times and then quit the session. In case the other endpoint is in the > midst of sending a large message, a response may take longer than the > request time out value. This will result in a number of duplicate > messages received. There should be a better way to handle this. Why > resend in the first place, especially if the connection is active? > > Also, what is the motivation for making retransmissions with a different > TR-ID? Doesn't this go agains the idea of retrying the request? > > Regards, > Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:45:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12527 for ; Fri, 17 Oct 2003 13:45:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYew-0001Aj-1y for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:45:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHj6qa004502 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYev-0001AX-Sv for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12484; Fri, 17 Oct 2003 13:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYet-0006G9-00; Fri, 17 Oct 2003 13:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYes-0006G6-00; Fri, 17 Oct 2003 13:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYes-00018i-5x; Fri, 17 Oct 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYeN-00018G-AO for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:44:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12465 for ; Fri, 17 Oct 2003 13:44:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYeL-0006Ff-00 for simple@ietf.org; Fri, 17 Oct 2003 13:44:29 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYeK-0006Fc-00 for simple@ietf.org; Fri, 17 Oct 2003 13:44:28 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHiLeY087640; Fri, 17 Oct 2003 12:44:28 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902A68.3060108@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <3F8EC115.4090305@nokia.com> In-Reply-To: <3F8EC115.4090305@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:44:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Based on recent discussions, I think we may need to rethink this. The point to resending was _not_ to build a reliability mechanism on top of TCP. We really wanted a mechanism to simply warn the user if we could not be sure the opposite endpoint had actually processed the message. I think we should either remove the text encouraging re-submission, or change it to re-use the same TR-ID, and add text to describe what the peer should do if it sees duplicate TR-IDs. Having a response delayed by a long request in the recipricol direction is a problem I don't think we have considered. I welcome input as to whether we think this is a real issue, and if so, how to deal with it. Aki Niemi wrote: > Hi, > > In the draft, if a SEND times out, the MSRP client is supposed to handle > this as if a 5xx was received. I.e., it will resend the message a few > times and then quit the session. In case the other endpoint is in the > midst of sending a large message, a response may take longer than the > request time out value. This will result in a number of duplicate > messages received. There should be a better way to handle this. Why > resend in the first place, especially if the connection is active? > > Also, what is the motivation for making retransmissions with a different > TR-ID? Doesn't this go agains the idea of retrying the request? > > Regards, > Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:49:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12751; Fri, 17 Oct 2003 13:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYji-0006KV-00; Fri, 17 Oct 2003 13:50:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYjh-0006KS-00; Fri, 17 Oct 2003 13:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYjh-0001NM-KP; Fri, 17 Oct 2003 13:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYim-0001JD-01 for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12699 for ; Fri, 17 Oct 2003 13:48:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYiX-0006Ip-00 for simple@ietf.org; Fri, 17 Oct 2003 13:48:49 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYiW-0006Im-00 for simple@ietf.org; Fri, 17 Oct 2003 13:48:49 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHmleY087973; Fri, 17 Oct 2003 12:48:48 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902B72.8060001@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments - Keepalive References: <3F8EC11A.4050803@nokia.com> In-Reply-To: <3F8EC11A.4050803@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:48:34 -0500 Content-Transfer-Encoding: 7bit The reasoning was, from a relay's perspective, it watchers for IM traffic to determine liveness. Clients that don't have any _other_ traffic to send should just generate some frome time to time. There is nothing particularly special about the traffic generated. Sending an empty message seemed to have exactly these semantics. From an endpoints perspective, I could see adding a new method if we wanted some special semantic handling that is different than for SEND. But I don't see how the receiver semantics for a "KEEPALIVE" method would be any different than for an empty SEND method. Aki Niemi wrote: > Hi, > > I know this is the sort of thing people usually use as flamebait, but I > just have to ask ;-) > > Why overload the SEND for keepalive? Is there a specific reason to > minimize the number of methods in this protocol? I don't see the > complexity added by having a function that clearly does something > specific have its own method name, too. > > Regards, > Aki > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:50:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12803 for ; Fri, 17 Oct 2003 13:50:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYjl-0001PK-Aw for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHo5p7005404 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYjl-0001P5-5T for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12751; Fri, 17 Oct 2003 13:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYji-0006KV-00; Fri, 17 Oct 2003 13:50:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYjh-0006KS-00; Fri, 17 Oct 2003 13:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYjh-0001NM-KP; Fri, 17 Oct 2003 13:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYim-0001JD-01 for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12699 for ; Fri, 17 Oct 2003 13:48:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYiX-0006Ip-00 for simple@ietf.org; Fri, 17 Oct 2003 13:48:49 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYiW-0006Im-00 for simple@ietf.org; Fri, 17 Oct 2003 13:48:49 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHmleY087973; Fri, 17 Oct 2003 12:48:48 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902B72.8060001@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments - Keepalive References: <3F8EC11A.4050803@nokia.com> In-Reply-To: <3F8EC11A.4050803@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:48:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The reasoning was, from a relay's perspective, it watchers for IM traffic to determine liveness. Clients that don't have any _other_ traffic to send should just generate some frome time to time. There is nothing particularly special about the traffic generated. Sending an empty message seemed to have exactly these semantics. From an endpoints perspective, I could see adding a new method if we wanted some special semantic handling that is different than for SEND. But I don't see how the receiver semantics for a "KEEPALIVE" method would be any different than for an empty SEND method. Aki Niemi wrote: > Hi, > > I know this is the sort of thing people usually use as flamebait, but I > just have to ask ;-) > > Why overload the SEND for keepalive? Is there a specific reason to > minimize the number of methods in this protocol? I don't see the > complexity added by having a function that clearly does something > specific have its own method name, too. > > Regards, > Aki > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:52:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12981; Fri, 17 Oct 2003 13:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYmd-0006Oa-00; Fri, 17 Oct 2003 13:53:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYmc-0006OV-00; Fri, 17 Oct 2003 13:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYmb-0001W3-Ie; Fri, 17 Oct 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYlp-0001UW-Tg for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12930 for ; Fri, 17 Oct 2003 13:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYln-0006NB-00 for simple@ietf.org; Fri, 17 Oct 2003 13:52:11 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYlm-0006N8-00 for simple@ietf.org; Fri, 17 Oct 2003 13:52:11 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHq9eY088285; Fri, 17 Oct 2003 12:52:10 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902C3C.2010006@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:51:56 -0500 Content-Transfer-Encoding: 7bit Markus, As I mentioned to Aki in a separate email, it is possible for the mixer device to require all content be wrapped in message/cpim (or any other wrapper, for that matter). It seems to me that this at least meets your item number 2. Is this not sufficient somehow? Markus.Isomaki@nokia.com wrote: > Hi, > > I think Aki has a very important point here. I would say that one of the essential drivers for having messaging sessions in the first place is the ability to use them as "media" in the SIP conferencing framework (or in the centralized conferencing a la XCON). In these kind of "chats" it is obviously mandatory that the recipients sees who the originator is. (BTW, this is one of the SIP services that also 3GPP is working on.) > > I see three ways forward: > 1. Fix this in MSRP base spec (I see that many people woudn't want this anymore at this stage, but still...) > 2. Define how MSRP can be extended and do this ASAP as the first extension > 3. Use MSGFMT somehow to support this feature > > My strong opinion is that MSRP should not allowed to proceed to IESG before there is some conclusion on this. At least to me MSRP without a simple way to support the conference scenario is worthless. There are already have plenty of solutions to send messages between two end-points and imitate a "session" (even SMS can do this), but SIP/MSRP solution's strenght should be really the multi-party case. > > Markus > > >>-----Original Message----- >>From: ext Aki Niemi [mailto:aki.niemi@nokia.com] >>Sent: 16 October, 2003 19:02 >>To: simple@ietf.org >>Subject: [Simple] Comments on MSRP - multiparty message >>session support >> >> >>Hi All, >> >>Since MSGFMT is no longer mandated (or is but only for CPIM >>gateways), >>how would a participant know where a message is coming from in a >>multiparty message session? >> >>Also, when using MSRP in a conferencing system, the lack of To/From >>prevents sending private messages efficiently within a multiparty >>session using an MSRP mixer as a "router" for them. >> >>So my question is this: what is the extensibility model for MSRP? For >>example, would it be possible to later on add this multiparty >>functionality as an extension, or would it be wise to think ahead >>already now? >> >>The draft includes some extensibility, e.g., for authentication >>algorithms, but I didn't immediately find much about adding >>methods and >>headers, and what to do with unknown headers. >> >>Regards, >>Aki >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:53:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13021 for ; Fri, 17 Oct 2003 13:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYmg-0001YT-6u for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHr60X005971 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYmg-0001YE-3Y for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12981; Fri, 17 Oct 2003 13:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYmd-0006Oa-00; Fri, 17 Oct 2003 13:53:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYmc-0006OV-00; Fri, 17 Oct 2003 13:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYmb-0001W3-Ie; Fri, 17 Oct 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYlp-0001UW-Tg for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12930 for ; Fri, 17 Oct 2003 13:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYln-0006NB-00 for simple@ietf.org; Fri, 17 Oct 2003 13:52:11 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYlm-0006N8-00 for simple@ietf.org; Fri, 17 Oct 2003 13:52:11 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHq9eY088285; Fri, 17 Oct 2003 12:52:10 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902C3C.2010006@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:51:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus, As I mentioned to Aki in a separate email, it is possible for the mixer device to require all content be wrapped in message/cpim (or any other wrapper, for that matter). It seems to me that this at least meets your item number 2. Is this not sufficient somehow? Markus.Isomaki@nokia.com wrote: > Hi, > > I think Aki has a very important point here. I would say that one of the essential drivers for having messaging sessions in the first place is the ability to use them as "media" in the SIP conferencing framework (or in the centralized conferencing a la XCON). In these kind of "chats" it is obviously mandatory that the recipients sees who the originator is. (BTW, this is one of the SIP services that also 3GPP is working on.) > > I see three ways forward: > 1. Fix this in MSRP base spec (I see that many people woudn't want this anymore at this stage, but still...) > 2. Define how MSRP can be extended and do this ASAP as the first extension > 3. Use MSGFMT somehow to support this feature > > My strong opinion is that MSRP should not allowed to proceed to IESG before there is some conclusion on this. At least to me MSRP without a simple way to support the conference scenario is worthless. There are already have plenty of solutions to send messages between two end-points and imitate a "session" (even SMS can do this), but SIP/MSRP solution's strenght should be really the multi-party case. > > Markus > > >>-----Original Message----- >>From: ext Aki Niemi [mailto:aki.niemi@nokia.com] >>Sent: 16 October, 2003 19:02 >>To: simple@ietf.org >>Subject: [Simple] Comments on MSRP - multiparty message >>session support >> >> >>Hi All, >> >>Since MSGFMT is no longer mandated (or is but only for CPIM >>gateways), >>how would a participant know where a message is coming from in a >>multiparty message session? >> >>Also, when using MSRP in a conferencing system, the lack of To/From >>prevents sending private messages efficiently within a multiparty >>session using an MSRP mixer as a "router" for them. >> >>So my question is this: what is the extensibility model for MSRP? For >>example, would it be possible to later on add this multiparty >>functionality as an extension, or would it be wise to think ahead >>already now? >> >>The draft includes some extensibility, e.g., for authentication >>algorithms, but I didn't immediately find much about adding >>methods and >>headers, and what to do with unknown headers. >> >>Regards, >>Aki >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 13:58:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13419; Fri, 17 Oct 2003 13:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYra-0006U4-00; Fri, 17 Oct 2003 13:58:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYra-0006U1-00; Fri, 17 Oct 2003 13:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYrQ-0001x8-Tl; Fri, 17 Oct 2003 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYqv-0001rq-Ke for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13284 for ; Fri, 17 Oct 2003 13:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYqt-0006SY-00 for simple@ietf.org; Fri, 17 Oct 2003 13:57:27 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYqs-0006SV-00 for simple@ietf.org; Fri, 17 Oct 2003 13:57:26 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHvIeY088701; Fri, 17 Oct 2003 12:57:24 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902D71.9020507@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: simple@ietf.org Subject: Re: [Simple] MSRP, SDP and CPIM References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:57:05 -0500 Content-Transfer-Encoding: 7bit Hi Pekka. Someone mentioned the "/" issue to me in at the WG meeting. Was that you? We have had some discussion between the authors on how to deal with this. I plan to have something in the next update. I think your approach is as good as anything we have come up with so far. As far as mandating that we always use message/cpim, we did require that at one time, but the wg consensus was for the protocol to allow any mime type. Pekka Pessi wrote: > Hi, > > First, I've a problem with SDP usage by MSRP. > > The format parameters on SDP media line should be tokens, and "/" is not > allowed within an SDP token. The token issue was discussed in MMUSIC wg, > and the wg consensus was to keep definition of token as is (and fix the > comment in sdp-new). > > So, the top-level media types should be put into an SDP attribute just > like accept-wrapped-types. Example: > > m=message 9999 msrp/tcp * > a=msrp-accept:message/cpim text/plain, text/html > > > Alternatively, we could mandate that the MSRP content should always be > Message/CPIM. The message/cpim itself mandates one header, Requires. So, > instead of > > m=message 9999 msrp/tcp message/cpim text/plain text/html > > we would have something like this > > m=message 9999 msrp/tcp cpim > a=msrp-accept: text/plain, text/html > > So, what would change at MSRP level? Currently we can have an MSRP message > like this: > > MSRP xx SEND > TR-ID: 123 > Content-Type: text/plain > > Hi, I'm Alice! > > Instead of that, we could have a CPIM message with implied MIME type > message/cpim (so, no Content-Type header in MSRP). Here we have CPIM > message without any CPIM headers: > > MSRP xx SEND > TR-ID: 123 > > > Content-Type: text/plain > > Hi, I'm Alice! > > So, we pay two extra pairs of CR-LF for CPIM support. > > Sender can always include CPIM headers, like From and To, > > MSRP xx SEND > TR-ID: 123 > > From: Alice > To: Bob > > Content-Type: text/plain > > Hi, I'm Alice! > > but the recipient can safely ignore them. The only exception is Requires > header. In order to properly process Requires, we need 420 Not > Supported, too. Then it might be possible to extend MSRP using CPIM > Requires header. > > Perhaps the supported or required extensions could be indicated as SDP > attributes, too. > > What about signed CPIM messages? The could be sent inside another one > > MSRP xx SEND > TR-ID: 123 > > My-Own-CPIM-Header: please see secured content > > Content-Type: multipart/signed; boundary=boundary; > micalg=sha1; > protocol=application/pkcs7-signature > > --boundary > Content-Type: message/cpim > > From: Alice > To: Bob > > Content-Type: text/plain > > Hi, I'm Alice! > > --boundary > Content-Type: application/pkcs7-signature > > (lots-of-binary-signature-here) > --boundary-- > > The real issue of CPIM is that it is just a wrapper around a MIME > object. This is not a problem with most SIP implementations, as they > already support MIME, but there may be some use of MSRP outside SIP? > > we could reuse CPIM header structure (quoting, line ending, etc) in > MSRP, if we choose to always have a message/cpim wrapper. I don't mean > that MSRP headers would be part of CPIM message, but that they reuse the > Header ABNF from CPIM. > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 13:58:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13489 for ; Fri, 17 Oct 2003 13:58:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYrd-00021R-O6 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:58:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHwDqb007767 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 13:58:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYrd-00021C-FS for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:58:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13419; Fri, 17 Oct 2003 13:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYra-0006U4-00; Fri, 17 Oct 2003 13:58:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYra-0006U1-00; Fri, 17 Oct 2003 13:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYrQ-0001x8-Tl; Fri, 17 Oct 2003 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYqv-0001rq-Ke for simple@optimus.ietf.org; Fri, 17 Oct 2003 13:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13284 for ; Fri, 17 Oct 2003 13:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYqt-0006SY-00 for simple@ietf.org; Fri, 17 Oct 2003 13:57:27 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AAYqs-0006SV-00 for simple@ietf.org; Fri, 17 Oct 2003 13:57:26 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9HHvIeY088701; Fri, 17 Oct 2003 12:57:24 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F902D71.9020507@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: simple@ietf.org Subject: Re: [Simple] MSRP, SDP and CPIM References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:57:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka. Someone mentioned the "/" issue to me in at the WG meeting. Was that you? We have had some discussion between the authors on how to deal with this. I plan to have something in the next update. I think your approach is as good as anything we have come up with so far. As far as mandating that we always use message/cpim, we did require that at one time, but the wg consensus was for the protocol to allow any mime type. Pekka Pessi wrote: > Hi, > > First, I've a problem with SDP usage by MSRP. > > The format parameters on SDP media line should be tokens, and "/" is not > allowed within an SDP token. The token issue was discussed in MMUSIC wg, > and the wg consensus was to keep definition of token as is (and fix the > comment in sdp-new). > > So, the top-level media types should be put into an SDP attribute just > like accept-wrapped-types. Example: > > m=message 9999 msrp/tcp * > a=msrp-accept:message/cpim text/plain, text/html > > > Alternatively, we could mandate that the MSRP content should always be > Message/CPIM. The message/cpim itself mandates one header, Requires. So, > instead of > > m=message 9999 msrp/tcp message/cpim text/plain text/html > > we would have something like this > > m=message 9999 msrp/tcp cpim > a=msrp-accept: text/plain, text/html > > So, what would change at MSRP level? Currently we can have an MSRP message > like this: > > MSRP xx SEND > TR-ID: 123 > Content-Type: text/plain > > Hi, I'm Alice! > > Instead of that, we could have a CPIM message with implied MIME type > message/cpim (so, no Content-Type header in MSRP). Here we have CPIM > message without any CPIM headers: > > MSRP xx SEND > TR-ID: 123 > > > Content-Type: text/plain > > Hi, I'm Alice! > > So, we pay two extra pairs of CR-LF for CPIM support. > > Sender can always include CPIM headers, like From and To, > > MSRP xx SEND > TR-ID: 123 > > From: Alice > To: Bob > > Content-Type: text/plain > > Hi, I'm Alice! > > but the recipient can safely ignore them. The only exception is Requires > header. In order to properly process Requires, we need 420 Not > Supported, too. Then it might be possible to extend MSRP using CPIM > Requires header. > > Perhaps the supported or required extensions could be indicated as SDP > attributes, too. > > What about signed CPIM messages? The could be sent inside another one > > MSRP xx SEND > TR-ID: 123 > > My-Own-CPIM-Header: please see secured content > > Content-Type: multipart/signed; boundary=boundary; > micalg=sha1; > protocol=application/pkcs7-signature > > --boundary > Content-Type: message/cpim > > From: Alice > To: Bob > > Content-Type: text/plain > > Hi, I'm Alice! > > --boundary > Content-Type: application/pkcs7-signature > > (lots-of-binary-signature-here) > --boundary-- > > The real issue of CPIM is that it is just a wrapper around a MIME > object. This is not a problem with most SIP implementations, as they > already support MIME, but there may be some use of MSRP outside SIP? > > we could reuse CPIM header structure (quoting, line ending, etc) in > MSRP, if we choose to always have a message/cpim wrapper. I don't mean > that MSRP headers would be part of CPIM message, but that they reuse the > Header ABNF from CPIM. > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 15:04:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16046; Fri, 17 Oct 2003 15:04:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZtS-0007C2-00; Fri, 17 Oct 2003 15:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZtR-0007Bz-00; Fri, 17 Oct 2003 15:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZtJ-0004hV-GM; Fri, 17 Oct 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZt1-0004h4-TO for simple@optimus.ietf.org; Fri, 17 Oct 2003 15:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15998 for ; Fri, 17 Oct 2003 15:03:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZsy-0007Bi-00 for simple@ietf.org; Fri, 17 Oct 2003 15:03:40 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AAZsx-0007BY-00 for simple@ietf.org; Fri, 17 Oct 2003 15:03:39 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9HJ3Aca001586 for ; Fri, 17 Oct 2003 15:03:11 -0400 (EDT) Message-ID: <3F903CEA.7090006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] What can you do with a list? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 15:03:06 -0400 Content-Transfer-Encoding: 7bit Folks, I'll be submitting a rev shortly to the xcap list draft: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt There have been few comments on this document; its pretty straightforward. One issue was raised to me privately by Markus, which I think merits broader discussion, is whether the scope of this draft is just presence lists, or whether it is broader than that. In a broader model, each URI representing a list has a set of permissible actions that can be taken against the list. We have "subscribable", which means you can subscribe to the list, but we could allow other things. For example, we could add "messageable", which means a MESSAGE request to that group we be exploded (using Gonzalo's terminology) to those members. "Invitable" would mean that an INVITE to that group would cause creation of a conference call to that group. Clearly this intersects with the conferencing work. So, there are two questions: (1) Do we want the draft to be broader than presence lists, and mention that these are lists to which different operations can be applied, (2) Assuming (1), do we want to add explicit support for a "messageable" boolean? I think we should definitely do (1), I have mixed feelings on (2), but am inclined to add it. Comments? THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 15:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16114 for ; Fri, 17 Oct 2003 15:04:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZtW-0004iP-0Z for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 15:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HJ4DnQ018119 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 15:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZtV-0004iA-Tl for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 15:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16046; Fri, 17 Oct 2003 15:04:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZtS-0007C2-00; Fri, 17 Oct 2003 15:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZtR-0007Bz-00; Fri, 17 Oct 2003 15:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZtJ-0004hV-GM; Fri, 17 Oct 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZt1-0004h4-TO for simple@optimus.ietf.org; Fri, 17 Oct 2003 15:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15998 for ; Fri, 17 Oct 2003 15:03:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZsy-0007Bi-00 for simple@ietf.org; Fri, 17 Oct 2003 15:03:40 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AAZsx-0007BY-00 for simple@ietf.org; Fri, 17 Oct 2003 15:03:39 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9HJ3Aca001586 for ; Fri, 17 Oct 2003 15:03:11 -0400 (EDT) Message-ID: <3F903CEA.7090006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] What can you do with a list? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 15:03:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I'll be submitting a rev shortly to the xcap list draft: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt There have been few comments on this document; its pretty straightforward. One issue was raised to me privately by Markus, which I think merits broader discussion, is whether the scope of this draft is just presence lists, or whether it is broader than that. In a broader model, each URI representing a list has a set of permissible actions that can be taken against the list. We have "subscribable", which means you can subscribe to the list, but we could allow other things. For example, we could add "messageable", which means a MESSAGE request to that group we be exploded (using Gonzalo's terminology) to those members. "Invitable" would mean that an INVITE to that group would cause creation of a conference call to that group. Clearly this intersects with the conferencing work. So, there are two questions: (1) Do we want the draft to be broader than presence lists, and mention that these are lists to which different operations can be applied, (2) Assuming (1), do we want to add explicit support for a "messageable" boolean? I think we should definitely do (1), I have mixed feelings on (2), but am inclined to add it. Comments? THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 17 15:09:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16782; Fri, 17 Oct 2003 15:09:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZz8-0007Ed-00; Fri, 17 Oct 2003 15:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZz7-0007Ea-00; Fri, 17 Oct 2003 15:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZz8-0005Mo-G9; Fri, 17 Oct 2003 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZyK-0005Lj-9u for simple@optimus.ietf.org; Fri, 17 Oct 2003 15:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16670 for ; Fri, 17 Oct 2003 15:09:01 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZyH-0007EA-00 for simple@ietf.org; Fri, 17 Oct 2003 15:09:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AAZyG-0007E7-00 for simple@ietf.org; Fri, 17 Oct 2003 15:09:08 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HJ914t021252; Fri, 17 Oct 2003 12:09:01 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HJ8xFB012419; Fri, 17 Oct 2003 12:09:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F903CEA.7090006@dynamicsoft.com> References: <3F903CEA.7090006@dynamicsoft.com> To: Jonathan Rosenberg , Simple WG Subject: Re: [Simple] What can you do with a list? Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:08:58 -0700 Hi Jonathan, I would suggest that if you decide to expand the scope of the work to include other permissible actions, that those actions be taken forward in separate drafts. That might require some re-writing of this draft (to make clear that the other drafts and actions may exist later), but it would allow the more mature work to proceed without blocking on the semantics of the other actions. Purely a personal commentary, regards, Ted Hardie At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: >Folks, > >I'll be submitting a rev shortly to the xcap list draft: >http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt > >There have been few comments on this document; its pretty straightforward. > >One issue was raised to me privately by Markus, which I think merits broader discussion, is whether the scope of this draft is just presence lists, or whether it is broader than that. In a broader model, each URI representing a list has a set of permissible actions that can be taken against the list. We have "subscribable", which means you can subscribe to the list, but we could allow other things. For example, we could add "messageable", which means a MESSAGE request to that group we be exploded (using Gonzalo's terminology) to those members. "Invitable" would mean that an INVITE to that group would cause creation of a conference call to that group. Clearly this intersects with the conferencing work. > >So, there are two questions: > >(1) Do we want the draft to be broader than presence lists, and mention that these are lists to which different operations can be applied, > >(2) Assuming (1), do we want to add explicit support for a "messageable" boolean? > >I think we should definitely do (1), I have mixed feelings on (2), but am inclined to add it. > >Comments? > >THanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 17 15:10:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16849 for ; Fri, 17 Oct 2003 15:10:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZzC-0005O5-CB for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 15:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HJA6BZ020703 for simple-archive@odin.ietf.org; Fri, 17 Oct 2003 15:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZzC-0005Nq-8o for simple-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 15:10:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16782; Fri, 17 Oct 2003 15:09:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZz8-0007Ed-00; Fri, 17 Oct 2003 15:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZz7-0007Ea-00; Fri, 17 Oct 2003 15:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZz8-0005Mo-G9; Fri, 17 Oct 2003 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZyK-0005Lj-9u for simple@optimus.ietf.org; Fri, 17 Oct 2003 15:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16670 for ; Fri, 17 Oct 2003 15:09:01 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZyH-0007EA-00 for simple@ietf.org; Fri, 17 Oct 2003 15:09:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AAZyG-0007E7-00 for simple@ietf.org; Fri, 17 Oct 2003 15:09:08 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HJ914t021252; Fri, 17 Oct 2003 12:09:01 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HJ8xFB012419; Fri, 17 Oct 2003 12:09:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F903CEA.7090006@dynamicsoft.com> References: <3F903CEA.7090006@dynamicsoft.com> To: Jonathan Rosenberg , Simple WG Subject: Re: [Simple] What can you do with a list? Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 12:08:58 -0700 Hi Jonathan, I would suggest that if you decide to expand the scope of the work to include other permissible actions, that those actions be taken forward in separate drafts. That might require some re-writing of this draft (to make clear that the other drafts and actions may exist later), but it would allow the more mature work to proceed without blocking on the semantics of the other actions. Purely a personal commentary, regards, Ted Hardie At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: >Folks, > >I'll be submitting a rev shortly to the xcap list draft: >http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt > >There have been few comments on this document; its pretty straightforward. > >One issue was raised to me privately by Markus, which I think merits broader discussion, is whether the scope of this draft is just presence lists, or whether it is broader than that. In a broader model, each URI representing a list has a set of permissible actions that can be taken against the list. We have "subscribable", which means you can subscribe to the list, but we could allow other things. For example, we could add "messageable", which means a MESSAGE request to that group we be exploded (using Gonzalo's terminology) to those members. "Invitable" would mean that an INVITE to that group would cause creation of a conference call to that group. Clearly this intersects with the conferencing work. > >So, there are two questions: > >(1) Do we want the draft to be broader than presence lists, and mention that these are lists to which different operations can be applied, > >(2) Assuming (1), do we want to add explicit support for a "messageable" boolean? > >I think we should definitely do (1), I have mixed feelings on (2), but am inclined to add it. > >Comments? > >THanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Oct 19 06:18:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04754; Sun, 19 Oct 2003 06:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABAeN-0004Gd-00; Sun, 19 Oct 2003 06:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABAeM-0004GY-00; Sun, 19 Oct 2003 06:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAeL-0004V6-6U; Sun, 19 Oct 2003 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAdb-0004Pb-3N for simple@optimus.ietf.org; Sun, 19 Oct 2003 06:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04737 for ; Sun, 19 Oct 2003 06:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABAdX-0004GH-00 for simple@ietf.org; Sun, 19 Oct 2003 06:18:11 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1ABAdW-0004GE-00 for simple@ietf.org; Sun, 19 Oct 2003 06:18:10 -0400 Received: from nt-mail.tlv.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Sun, 19 Oct 2003 12:17:38 +0200 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id <4DPLW8Q0>; Sun, 19 Oct 2003 12:17:38 +0200 Message-ID: <99FF181D4C99564F8D623069E1DDB25E3B8A92@nt-mail.tlv.radvision.com> From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] winfo-format question Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 19 Oct 2003 12:17:31 +0200 Hi. I have a question about the Watcher tag In a Winfo document: In winfo-format-04 it says that "The value of the watcher element is a URI for the watcher. This URI should be an address-of-record....". Should the watcher value always be taken as the From header of the incoming Subscribe request, or are there any scenarios in which the address-of-record will be other than the From header value? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Oct 19 06:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04777 for ; Sun, 19 Oct 2003 06:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAeS-0004WV-4H for simple-archive@odin.ietf.org; Sun, 19 Oct 2003 06:19:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JAJ8Cg017387 for simple-archive@odin.ietf.org; Sun, 19 Oct 2003 06:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAeR-0004WH-Q6 for simple-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 06:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04754; Sun, 19 Oct 2003 06:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABAeN-0004Gd-00; Sun, 19 Oct 2003 06:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABAeM-0004GY-00; Sun, 19 Oct 2003 06:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAeL-0004V6-6U; Sun, 19 Oct 2003 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAdb-0004Pb-3N for simple@optimus.ietf.org; Sun, 19 Oct 2003 06:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04737 for ; Sun, 19 Oct 2003 06:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABAdX-0004GH-00 for simple@ietf.org; Sun, 19 Oct 2003 06:18:11 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1ABAdW-0004GE-00 for simple@ietf.org; Sun, 19 Oct 2003 06:18:10 -0400 Received: from nt-mail.tlv.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Sun, 19 Oct 2003 12:17:38 +0200 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id <4DPLW8Q0>; Sun, 19 Oct 2003 12:17:38 +0200 Message-ID: <99FF181D4C99564F8D623069E1DDB25E3B8A92@nt-mail.tlv.radvision.com> From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] winfo-format question Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 19 Oct 2003 12:17:31 +0200 Hi. I have a question about the Watcher tag In a Winfo document: In winfo-format-04 it says that "The value of the watcher element is a URI for the watcher. This URI should be an address-of-record....". Should the watcher value always be taken as the From header of the incoming Subscribe request, or are there any scenarios in which the address-of-record will be other than the From header value? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Oct 19 16:46:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18882; Sun, 19 Oct 2003 16:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABKS8-0000Jg-00; Sun, 19 Oct 2003 16:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABKS8-0000Jd-00; Sun, 19 Oct 2003 16:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKS5-0004Tc-B4; Sun, 19 Oct 2003 16:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKRf-0004Pn-08 for simple@optimus.ietf.org; Sun, 19 Oct 2003 16:46:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18879 for ; Sun, 19 Oct 2003 16:46:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABKRc-0000JX-00 for simple@ietf.org; Sun, 19 Oct 2003 16:46:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ABKRc-0000JU-00 for simple@ietf.org; Sun, 19 Oct 2003 16:46:32 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9JKk6ca002293; Sun, 19 Oct 2003 16:46:06 -0400 (EDT) Message-ID: <3F92F809.1020004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] winfo-format question References: <99FF181D4C99564F8D623069E1DDB25E3B8A92@nt-mail.tlv.radvision.com> In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E3B8A92@nt-mail.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 19 Oct 2003 16:46:01 -0400 Content-Transfer-Encoding: 7bit Normally this would be whatever identity was authenticated by the server. That may have been obtained through digest authentication, S/MIME, P-Asserted-ID or through AIB. From would probably be a "last resort" when, for some reason, a server has accepted a subscription without authentication. Thanks, Jonathan R. Orly Rosenberg wrote: > Hi. > I have a question about the Watcher tag In a Winfo document: > In winfo-format-04 it says that "The value of the watcher element is a URI > for the watcher. > This URI should be an address-of-record....". > Should the watcher value always be taken as the From header of the incoming > Subscribe request, > or are there any scenarios in which the address-of-record will be other than > the From header value? > > Thanks, > Orly Rosenberg. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Oct 19 16:47:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18902 for ; Sun, 19 Oct 2003 16:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKSB-0004UZ-ER for simple-archive@odin.ietf.org; Sun, 19 Oct 2003 16:47:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JKl7Ln017260 for simple-archive@odin.ietf.org; Sun, 19 Oct 2003 16:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKSB-0004UJ-5q for simple-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 16:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18882; Sun, 19 Oct 2003 16:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABKS8-0000Jg-00; Sun, 19 Oct 2003 16:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABKS8-0000Jd-00; Sun, 19 Oct 2003 16:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKS5-0004Tc-B4; Sun, 19 Oct 2003 16:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKRf-0004Pn-08 for simple@optimus.ietf.org; Sun, 19 Oct 2003 16:46:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18879 for ; Sun, 19 Oct 2003 16:46:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABKRc-0000JX-00 for simple@ietf.org; Sun, 19 Oct 2003 16:46:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ABKRc-0000JU-00 for simple@ietf.org; Sun, 19 Oct 2003 16:46:32 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9JKk6ca002293; Sun, 19 Oct 2003 16:46:06 -0400 (EDT) Message-ID: <3F92F809.1020004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] winfo-format question References: <99FF181D4C99564F8D623069E1DDB25E3B8A92@nt-mail.tlv.radvision.com> In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E3B8A92@nt-mail.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 19 Oct 2003 16:46:01 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Normally this would be whatever identity was authenticated by the server. That may have been obtained through digest authentication, S/MIME, P-Asserted-ID or through AIB. From would probably be a "last resort" when, for some reason, a server has accepted a subscription without authentication. Thanks, Jonathan R. Orly Rosenberg wrote: > Hi. > I have a question about the Watcher tag In a Winfo document: > In winfo-format-04 it says that "The value of the watcher element is a URI > for the watcher. > This URI should be an address-of-record....". > Should the watcher value always be taken as the From header of the incoming > Subscribe request, > or are there any scenarios in which the address-of-record will be other than > the From header value? > > Thanks, > Orly Rosenberg. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Oct 19 17:05:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19750; Sun, 19 Oct 2003 17:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKjW-0000vE-9B; Sun, 19 Oct 2003 17:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKjC-0000sq-5X for simple@optimus.ietf.org; Sun, 19 Oct 2003 17:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19706 for ; Sun, 19 Oct 2003 17:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABKj9-0000YL-00 for simple@ietf.org; Sun, 19 Oct 2003 17:04:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ABKj9-0000Y3-00 for simple@ietf.org; Sun, 19 Oct 2003 17:04:39 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9JL4Dca002307; Sun, 19 Oct 2003 17:04:13 -0400 (EDT) Message-ID: <3F92FC48.2010504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Simple WG Subject: Re: [Simple] What can you do with a list? References: <3F903CEA.7090006@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 19 Oct 2003 17:04:08 -0400 Content-Transfer-Encoding: 7bit Ted, What you are talking about would correspond to saying yes to option (1) below, and no to option (2). Scope creep and immaturity were some of the reasons for my mixed feelings on (2). Does anyone strongly believe it should be added? Thanks, Jonathan R. hardie@qualcomm.com wrote: > Hi Jonathan, I would suggest that if you decide to expand the scope > of the work to include other permissible actions, that those > actions be taken forward in separate drafts. That might require > some re-writing of this draft (to make clear that the other drafts > and actions may exist later), but it would allow the more mature > work to proceed without blocking on the semantics of the other > actions. Purely a personal commentary, regards, Ted Hardie > > > > At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: > >> Folks, >> >> I'll be submitting a rev shortly to the xcap list draft: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt >> >> >> There have been few comments on this document; its pretty >> straightforward. >> >> One issue was raised to me privately by Markus, which I think >> merits broader discussion, is whether the scope of this draft is >> just presence lists, or whether it is broader than that. In a >> broader model, each URI representing a list has a set of >> permissible actions that can be taken against the list. We have >> "subscribable", which means you can subscribe to the list, but we >> could allow other things. For example, we could add >> "messageable", which means a MESSAGE request to that group we be >> exploded (using Gonzalo's terminology) to those members. >> "Invitable" would mean that an INVITE to that group would cause >> creation of a conference call to that group. Clearly this >> intersects with the conferencing work. >> >> So, there are two questions: >> >> (1) Do we want the draft to be broader than presence lists, and >> mention that these are lists to which different operations can be >> applied, >> >> (2) Assuming (1), do we want to add explicit support for a >> "messageable" boolean? >> >> I think we should definitely do (1), I have mixed feelings on >> (2), but am inclined to add it. >> >> Comments? >> >> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. >> 600 Lanidex Plaza Chief Technology Officer >> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.dynamicsoft.com >> >> >> >> _______________________________________________ Simple mailing >> list Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Oct 19 17:06:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19771 for ; Sun, 19 Oct 2003 17:06:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKkA-00013o-Ke for simple-archive@odin.ietf.org; Sun, 19 Oct 2003 17:05:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JL5giZ004070 for simple-archive@odin.ietf.org; Sun, 19 Oct 2003 17:05:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKkA-00013Z-G0 for simple-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 17:05:42 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19750; Sun, 19 Oct 2003 17:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKjW-0000vE-9B; Sun, 19 Oct 2003 17:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABKjC-0000sq-5X for simple@optimus.ietf.org; Sun, 19 Oct 2003 17:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19706 for ; Sun, 19 Oct 2003 17:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABKj9-0000YL-00 for simple@ietf.org; Sun, 19 Oct 2003 17:04:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ABKj9-0000Y3-00 for simple@ietf.org; Sun, 19 Oct 2003 17:04:39 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9JL4Dca002307; Sun, 19 Oct 2003 17:04:13 -0400 (EDT) Message-ID: <3F92FC48.2010504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Simple WG Subject: Re: [Simple] What can you do with a list? References: <3F903CEA.7090006@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 19 Oct 2003 17:04:08 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ted, What you are talking about would correspond to saying yes to option (1) below, and no to option (2). Scope creep and immaturity were some of the reasons for my mixed feelings on (2). Does anyone strongly believe it should be added? Thanks, Jonathan R. hardie@qualcomm.com wrote: > Hi Jonathan, I would suggest that if you decide to expand the scope > of the work to include other permissible actions, that those > actions be taken forward in separate drafts. That might require > some re-writing of this draft (to make clear that the other drafts > and actions may exist later), but it would allow the more mature > work to proceed without blocking on the semantics of the other > actions. Purely a personal commentary, regards, Ted Hardie > > > > At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: > >> Folks, >> >> I'll be submitting a rev shortly to the xcap list draft: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt >> >> >> There have been few comments on this document; its pretty >> straightforward. >> >> One issue was raised to me privately by Markus, which I think >> merits broader discussion, is whether the scope of this draft is >> just presence lists, or whether it is broader than that. In a >> broader model, each URI representing a list has a set of >> permissible actions that can be taken against the list. We have >> "subscribable", which means you can subscribe to the list, but we >> could allow other things. For example, we could add >> "messageable", which means a MESSAGE request to that group we be >> exploded (using Gonzalo's terminology) to those members. >> "Invitable" would mean that an INVITE to that group would cause >> creation of a conference call to that group. Clearly this >> intersects with the conferencing work. >> >> So, there are two questions: >> >> (1) Do we want the draft to be broader than presence lists, and >> mention that these are lists to which different operations can be >> applied, >> >> (2) Assuming (1), do we want to add explicit support for a >> "messageable" boolean? >> >> I think we should definitely do (1), I have mixed feelings on >> (2), but am inclined to add it. >> >> Comments? >> >> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. >> 600 Lanidex Plaza Chief Technology Officer >> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.dynamicsoft.com >> >> >> >> _______________________________________________ Simple mailing >> list Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 03:53:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16561; Mon, 20 Oct 2003 03:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABUqj-0005MO-00; Mon, 20 Oct 2003 03:53:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABUqi-0005ML-00; Mon, 20 Oct 2003 03:53:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUqb-0000BD-H3; Mon, 20 Oct 2003 03:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUqH-00007t-8I for simple@optimus.ietf.org; Mon, 20 Oct 2003 03:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16549 for ; Mon, 20 Oct 2003 03:52:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABUqE-0005M5-00 for simple@ietf.org; Mon, 20 Oct 2003 03:52:38 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1ABUqD-0005Lx-00 for simple@ietf.org; Mon, 20 Oct 2003 03:52:37 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 20 Oct 2003 08:55:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] What can you do with a list? Message-ID: <45730E094814E44488F789C1CDED27AE01E22E2E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] What can you do with a list? Thread-Index: AcOWhLF4X7uw/A4NSBmhu3UFtc3lqgAWga1g From: "Chris Boulton" To: "Jonathan Rosenberg" , Cc: "Simple WG" Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 08:52:37 +0100 Content-Transfer-Encoding: quoted-printable Jonathan, I agree with Ted on this one - I certainly think it would be beneficial to open up lists for other operations BUT these should be extensions from the base draft. So (1) and not (2). Chris. >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 19 October 2003 22:04 >To: hardie@qualcomm.com >Cc: Simple WG >Subject: Re: [Simple] What can you do with a list? > >Ted, > >What you are talking about would correspond to saying yes to option >(1) below, and no to option (2). Scope creep and immaturity were some >of the reasons for my mixed feelings on (2). Does anyone strongly >believe it should be added? > >Thanks, >Jonathan R. > >hardie@qualcomm.com wrote: > >> Hi Jonathan, I would suggest that if you decide to expand the scope >> of the work to include other permissible actions, that those >> actions be taken forward in separate drafts. That might require >> some re-writing of this draft (to make clear that the other drafts >> and actions may exist later), but it would allow the more mature >> work to proceed without blocking on the semantics of the other >> actions. Purely a personal commentary, regards, Ted Hardie >> >> >> >> At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: >> >>> Folks, >>> >>> I'll be submitting a rev shortly to the xcap list draft: >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage- >00.txt >>> >>> >>> There have been few comments on this document; its pretty >>> straightforward. >>> >>> One issue was raised to me privately by Markus, which I think >>> merits broader discussion, is whether the scope of this draft is >>> just presence lists, or whether it is broader than that. In a >>> broader model, each URI representing a list has a set of >>> permissible actions that can be taken against the list. We have >>> "subscribable", which means you can subscribe to the list, but we >>> could allow other things. For example, we could add >>> "messageable", which means a MESSAGE request to that group we be >>> exploded (using Gonzalo's terminology) to those members. >>> "Invitable" would mean that an INVITE to that group would cause >>> creation of a conference call to that group. Clearly this >>> intersects with the conferencing work. >>> >>> So, there are two questions: >>> >>> (1) Do we want the draft to be broader than presence lists, and >>> mention that these are lists to which different operations can be >>> applied, >>> >>> (2) Assuming (1), do we want to add explicit support for a >>> "messageable" boolean? >>> >>> I think we should definitely do (1), I have mixed feelings on >>> (2), but am inclined to add it. >>> >>> Comments? >>> >>> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. >>> 600 Lanidex Plaza Chief Technology Officer >>> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >>> FAX: (973) 952-5050 http://www.jdrosen.net >>> PHONE: (973) 952-5000 http://www.dynamicsoft.com >>> >>> >>> >>> _______________________________________________ Simple mailing >>> list Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 03:53:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16588 for ; Mon, 20 Oct 2003 03:53:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUqm-0000DJ-Mi for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 03:53:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K7rCHY000820 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 03:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUqm-0000D5-GR for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 03:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16561; Mon, 20 Oct 2003 03:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABUqj-0005MO-00; Mon, 20 Oct 2003 03:53:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABUqi-0005ML-00; Mon, 20 Oct 2003 03:53:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUqb-0000BD-H3; Mon, 20 Oct 2003 03:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUqH-00007t-8I for simple@optimus.ietf.org; Mon, 20 Oct 2003 03:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16549 for ; Mon, 20 Oct 2003 03:52:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABUqE-0005M5-00 for simple@ietf.org; Mon, 20 Oct 2003 03:52:38 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1ABUqD-0005Lx-00 for simple@ietf.org; Mon, 20 Oct 2003 03:52:37 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 20 Oct 2003 08:55:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] What can you do with a list? Message-ID: <45730E094814E44488F789C1CDED27AE01E22E2E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] What can you do with a list? Thread-Index: AcOWhLF4X7uw/A4NSBmhu3UFtc3lqgAWga1g From: "Chris Boulton" To: "Jonathan Rosenberg" , Cc: "Simple WG" Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 08:52:37 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jonathan, I agree with Ted on this one - I certainly think it would be beneficial to open up lists for other operations BUT these should be extensions from the base draft. So (1) and not (2). Chris. >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 19 October 2003 22:04 >To: hardie@qualcomm.com >Cc: Simple WG >Subject: Re: [Simple] What can you do with a list? > >Ted, > >What you are talking about would correspond to saying yes to option >(1) below, and no to option (2). Scope creep and immaturity were some >of the reasons for my mixed feelings on (2). Does anyone strongly >believe it should be added? > >Thanks, >Jonathan R. > >hardie@qualcomm.com wrote: > >> Hi Jonathan, I would suggest that if you decide to expand the scope >> of the work to include other permissible actions, that those >> actions be taken forward in separate drafts. That might require >> some re-writing of this draft (to make clear that the other drafts >> and actions may exist later), but it would allow the more mature >> work to proceed without blocking on the semantics of the other >> actions. Purely a personal commentary, regards, Ted Hardie >> >> >> >> At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: >> >>> Folks, >>> >>> I'll be submitting a rev shortly to the xcap list draft: >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage- >00.txt >>> >>> >>> There have been few comments on this document; its pretty >>> straightforward. >>> >>> One issue was raised to me privately by Markus, which I think >>> merits broader discussion, is whether the scope of this draft is >>> just presence lists, or whether it is broader than that. In a >>> broader model, each URI representing a list has a set of >>> permissible actions that can be taken against the list. We have >>> "subscribable", which means you can subscribe to the list, but we >>> could allow other things. For example, we could add >>> "messageable", which means a MESSAGE request to that group we be >>> exploded (using Gonzalo's terminology) to those members. >>> "Invitable" would mean that an INVITE to that group would cause >>> creation of a conference call to that group. Clearly this >>> intersects with the conferencing work. >>> >>> So, there are two questions: >>> >>> (1) Do we want the draft to be broader than presence lists, and >>> mention that these are lists to which different operations can be >>> applied, >>> >>> (2) Assuming (1), do we want to add explicit support for a >>> "messageable" boolean? >>> >>> I think we should definitely do (1), I have mixed feelings on >>> (2), but am inclined to add it. >>> >>> Comments? >>> >>> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. >>> 600 Lanidex Plaza Chief Technology Officer >>> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >>> FAX: (973) 952-5050 http://www.jdrosen.net >>> PHONE: (973) 952-5000 http://www.dynamicsoft.com >>> >>> >>> >>> _______________________________________________ Simple mailing >>> list Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 06:04:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19622; Mon, 20 Oct 2003 06:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABWtb-0006K1-00; Mon, 20 Oct 2003 06:04:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABWta-0006Jy-00; Mon, 20 Oct 2003 06:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABWtN-00060s-CF; Mon, 20 Oct 2003 06:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABWsR-0005o3-JS for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19605 for ; Mon, 20 Oct 2003 06:02:52 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABWsN-0006JT-00 for simple@ietf.org; Mon, 20 Oct 2003 06:02:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABWsM-0006JQ-00 for simple@ietf.org; Mon, 20 Oct 2003 06:02:59 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KA2xX04011 for ; Mon, 20 Oct 2003 13:02:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 13:02:58 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 13:02:58 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 13:02:58 +0300 content-class: urn:content-classes:message Subject: RE: [Simple] MSRP Comments - Keepalive MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A1@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQ To: Cc: X-OriginalArrivalTime: 20 Oct 2003 10:02:58.0545 (UTC) FILETIME=[56E21E10:01C396F1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:02:57 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 17 October, 2003 20:49 > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Comments - Keepalive >=20 >=20 > The reasoning was, from a relay's perspective, it watchers for IM=20 > traffic to determine liveness. Clients that don't have any _other_=20 > traffic to send should just generate some frome time to=20 > time. There is=20 > nothing particularly special about the traffic generated. Sending an=20 > empty message seemed to have exactly these semantics. I don't think there is anything wrong with this reasoning. > From an endpoints perspective, I could see adding a new=20 > method if we=20 > wanted some special semantic handling that is different than=20 > for SEND.=20 > But I don't see how the receiver semantics for a "KEEPALIVE" method=20 > would be any different than for an empty SEND method. That is certainly true. I don't think there is a difference in = semantics. Where I think something like KEEPALIVE would help is in specification = clarity. I think it's better to keep things explicit. If in total, this = would save a few posts on sip-implementors that doubt the "special" = nature of a SEND without a body, then I think it's worth doing. On the other hand, as a drawback to the KEEPALIVE method, it would = require defining a new method with it's associated specification work, = which I don't believe is a considerable burden though. Is there any = other reason to prefer an empty SEND over a KEEPALIVE? Regards, Aki =20 >=20 > Aki Niemi wrote: >=20 > > Hi, > >=20 > > I know this is the sort of thing people usually use as=20 > flamebait, but I=20 > > just have to ask ;-) > >=20 > > Why overload the SEND for keepalive? Is there a specific reason to=20 > > minimize the number of methods in this protocol? I don't see the=20 > > complexity added by having a function that clearly does something=20 > > specific have its own method name, too. > >=20 > > Regards, > > Aki > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 06:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19644 for ; Mon, 20 Oct 2003 06:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABWtf-00066W-Q1 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:04:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KA4JT4023463 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABWtf-000660-C0 for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 06:04:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19622; Mon, 20 Oct 2003 06:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABWtb-0006K1-00; Mon, 20 Oct 2003 06:04:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABWta-0006Jy-00; Mon, 20 Oct 2003 06:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABWtN-00060s-CF; Mon, 20 Oct 2003 06:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABWsR-0005o3-JS for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19605 for ; Mon, 20 Oct 2003 06:02:52 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABWsN-0006JT-00 for simple@ietf.org; Mon, 20 Oct 2003 06:02:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABWsM-0006JQ-00 for simple@ietf.org; Mon, 20 Oct 2003 06:02:59 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KA2xX04011 for ; Mon, 20 Oct 2003 13:02:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 13:02:58 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 13:02:58 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 13:02:58 +0300 content-class: urn:content-classes:message Subject: RE: [Simple] MSRP Comments - Keepalive MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A1@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQ To: Cc: X-OriginalArrivalTime: 20 Oct 2003 10:02:58.0545 (UTC) FILETIME=[56E21E10:01C396F1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:02:57 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 17 October, 2003 20:49 > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Comments - Keepalive >=20 >=20 > The reasoning was, from a relay's perspective, it watchers for IM=20 > traffic to determine liveness. Clients that don't have any _other_=20 > traffic to send should just generate some frome time to=20 > time. There is=20 > nothing particularly special about the traffic generated. Sending an=20 > empty message seemed to have exactly these semantics. I don't think there is anything wrong with this reasoning. > From an endpoints perspective, I could see adding a new=20 > method if we=20 > wanted some special semantic handling that is different than=20 > for SEND.=20 > But I don't see how the receiver semantics for a "KEEPALIVE" method=20 > would be any different than for an empty SEND method. That is certainly true. I don't think there is a difference in = semantics. Where I think something like KEEPALIVE would help is in specification = clarity. I think it's better to keep things explicit. If in total, this = would save a few posts on sip-implementors that doubt the "special" = nature of a SEND without a body, then I think it's worth doing. On the other hand, as a drawback to the KEEPALIVE method, it would = require defining a new method with it's associated specification work, = which I don't believe is a considerable burden though. Is there any = other reason to prefer an empty SEND over a KEEPALIVE? Regards, Aki =20 >=20 > Aki Niemi wrote: >=20 > > Hi, > >=20 > > I know this is the sort of thing people usually use as=20 > flamebait, but I=20 > > just have to ask ;-) > >=20 > > Why overload the SEND for keepalive? Is there a specific reason to=20 > > minimize the number of methods in this protocol? I don't see the=20 > > complexity added by having a function that clearly does something=20 > > specific have its own method name, too. > >=20 > > Regards, > > Aki > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 06:16:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19913; Mon, 20 Oct 2003 06:16:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABX5e-0006Q6-00; Mon, 20 Oct 2003 06:16:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABX5e-0006Q2-00; Mon, 20 Oct 2003 06:16:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABX50-0000lb-5D; Mon, 20 Oct 2003 06:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABX4A-0000dM-IH for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:15:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19885 for ; Mon, 20 Oct 2003 06:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABX46-0006PA-00 for simple@ietf.org; Mon, 20 Oct 2003 06:15:06 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1ABX45-0006P7-00 for simple@ietf.org; Mon, 20 Oct 2003 06:15:06 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 20 Oct 2003 11:17:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Comments - Keepalive Message-ID: <45730E094814E44488F789C1CDED27AE0219B0EC@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQABiapjA= From: "Chris Boulton" To: , Cc: Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 11:15:08 +0100 Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] >Sent: 20 October 2003 11:03 >To: bcampbell@dynamicsoft.com >Cc: simple@ietf.org >Subject: RE: [Simple] MSRP Comments - Keepalive > > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 17 October, 2003 20:49 > > To: Niemi Aki (NMP/Helsinki) > > Cc: simple@ietf.org > > Subject: Re: [Simple] MSRP Comments - Keepalive > > > > > > The reasoning was, from a relay's perspective, it watchers for IM > > traffic to determine liveness. Clients that don't have any _other_ > > traffic to send should just generate some frome time to > > time. There is > > nothing particularly special about the traffic generated. Sending an > > empty message seemed to have exactly these semantics. > >I don't think there is anything wrong with this reasoning. > > > From an endpoints perspective, I could see adding a new > > method if we > > wanted some special semantic handling that is different than > > for SEND. > > But I don't see how the receiver semantics for a "KEEPALIVE" method > > would be any different than for an empty SEND method. > >That is certainly true. I don't think there is a difference in semantics. > >Where I think something like KEEPALIVE would help is in specification >clarity. I think it's better to keep things explicit. If in total, this >would save a few posts on sip-implementors that doubt the "special" nature >of a SEND without a body, then I think it's worth doing. > >On the other hand, as a drawback to the KEEPALIVE method, it would require >defining a new method with it's associated specification work, which I >don't believe is a considerable burden though. Is there any other reason to >prefer an empty SEND over a KEEPALIVE? [Chris Boulton] The only real reason I can think of is to maintain the 'lets keep it simple and light weight' philosophy that MSRP champions. I don't have a problem with creating a new method for this functionality BUT I think we need to be careful when crating new methods for functionality where appropriate semantics already exist. As long as the refresh operation is explicitly defined, I just don't see the need. Chris. > >Regards, >Aki > > > > > Aki Niemi wrote: > > > > > Hi, > > > > > > I know this is the sort of thing people usually use as > > flamebait, but I > > > just have to ask ;-) > > > > > > Why overload the SEND for keepalive? Is there a specific reason to > > > minimize the number of methods in this protocol? I don't see the > > > complexity added by having a function that clearly does something > > > specific have its own method name, too. > > > > > > Regards, > > > Aki > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 06:17:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19937 for ; Mon, 20 Oct 2003 06:17:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABX5j-00011y-J9 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:16:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KAGlka003963 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABX5j-00011q-D0 for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 06:16:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19913; Mon, 20 Oct 2003 06:16:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABX5e-0006Q6-00; Mon, 20 Oct 2003 06:16:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABX5e-0006Q2-00; Mon, 20 Oct 2003 06:16:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABX50-0000lb-5D; Mon, 20 Oct 2003 06:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABX4A-0000dM-IH for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:15:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19885 for ; Mon, 20 Oct 2003 06:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABX46-0006PA-00 for simple@ietf.org; Mon, 20 Oct 2003 06:15:06 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1ABX45-0006P7-00 for simple@ietf.org; Mon, 20 Oct 2003 06:15:06 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 20 Oct 2003 11:17:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Comments - Keepalive Message-ID: <45730E094814E44488F789C1CDED27AE0219B0EC@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQABiapjA= From: "Chris Boulton" To: , Cc: Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 11:15:08 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] >Sent: 20 October 2003 11:03 >To: bcampbell@dynamicsoft.com >Cc: simple@ietf.org >Subject: RE: [Simple] MSRP Comments - Keepalive > > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 17 October, 2003 20:49 > > To: Niemi Aki (NMP/Helsinki) > > Cc: simple@ietf.org > > Subject: Re: [Simple] MSRP Comments - Keepalive > > > > > > The reasoning was, from a relay's perspective, it watchers for IM > > traffic to determine liveness. Clients that don't have any _other_ > > traffic to send should just generate some frome time to > > time. There is > > nothing particularly special about the traffic generated. Sending an > > empty message seemed to have exactly these semantics. > >I don't think there is anything wrong with this reasoning. > > > From an endpoints perspective, I could see adding a new > > method if we > > wanted some special semantic handling that is different than > > for SEND. > > But I don't see how the receiver semantics for a "KEEPALIVE" method > > would be any different than for an empty SEND method. > >That is certainly true. I don't think there is a difference in semantics. > >Where I think something like KEEPALIVE would help is in specification >clarity. I think it's better to keep things explicit. If in total, this >would save a few posts on sip-implementors that doubt the "special" nature >of a SEND without a body, then I think it's worth doing. > >On the other hand, as a drawback to the KEEPALIVE method, it would require >defining a new method with it's associated specification work, which I >don't believe is a considerable burden though. Is there any other reason to >prefer an empty SEND over a KEEPALIVE? [Chris Boulton] The only real reason I can think of is to maintain the 'lets keep it simple and light weight' philosophy that MSRP champions. I don't have a problem with creating a new method for this functionality BUT I think we need to be careful when crating new methods for functionality where appropriate semantics already exist. As long as the refresh operation is explicitly defined, I just don't see the need. Chris. > >Regards, >Aki > > > > > Aki Niemi wrote: > > > > > Hi, > > > > > > I know this is the sort of thing people usually use as > > flamebait, but I > > > just have to ask ;-) > > > > > > Why overload the SEND for keepalive? Is there a specific reason to > > > minimize the number of methods in this protocol? I don't see the > > > complexity added by having a function that clearly does something > > > specific have its own method name, too. > > > > > > Regards, > > > Aki > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 06:26:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20047; Mon, 20 Oct 2003 06:26:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXFL-0006So-00; Mon, 20 Oct 2003 06:26:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXFL-0006Sj-00; Mon, 20 Oct 2003 06:26:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXEg-0003IA-Re; Mon, 20 Oct 2003 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXEC-0003Cc-F3 for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20032 for ; Mon, 20 Oct 2003 06:25:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXE7-0006SJ-00 for simple@ietf.org; Mon, 20 Oct 2003 06:25:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXE6-0006S8-00 for simple@ietf.org; Mon, 20 Oct 2003 06:25:26 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KAPQX03624 for ; Mon, 20 Oct 2003 13:25:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 13:25:25 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 13:25:25 +0300 content-class: urn:content-classes:message Subject: RE: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A3@esebe013.ntc.nokia.com> Thread-Topic: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) Thread-Index: AcOUwWlMtFY7cuBMQ6ieFkc8jxCYhACMfpzQ To: Cc: , , X-OriginalArrivalTime: 20 Oct 2003 10:25:25.0852 (UTC) FILETIME=[79F0D9C0:01C396F4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:25:25 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 17 October, 2003 18:14 > To: Niemi Aki (NMP/Helsinki) > Cc: pkyzivat@cisco.com; rsparks@dynamicsoft.com; simple@ietf.org > Subject: MSRP: resuming sessions (was Re: [Simple] Chair=20 > call for group > opinion (was MSRP: Administrative shutdown of relays)) >=20 >=20 > aki.niemi@nokia.com wrote: >=20 > [...] >=20 > > Is this acceptable? A lot of the discussion so far has=20 > made the assumption that an MSRP client would reconnect and=20 > resend if there is a timeout, a 5xx, or the connection to=20 > the relay closes. That isn't the defined behavior, it=20 > actually goes against the defined behavior. > >=20 > > Bullet 5, Ch 7.4.3: > >=20 > > If the endpoint receives 5xx responses more than some threshold > > number of times in a row, it SHOULD assume the session has > > failed, and initiate tear-down via the signaling protocol. >=20 > Sure, it says the connection should be torn down. It does not say=20 > anything at all about whether a client should automatically=20 > attempt to=20 > create a new session or not. I don't think we should specify=20 > that sort=20 > of behavior one way or another. It does not seem to affect=20 > interoperability in any way. OK, then I misinterpreted you before. I thought by auto-resume, the MSRP = client would try to resume the *MSRP* session, meaning something like = establish a new TCP connection, do a VISIT, etc. Maybe some = clarification to the term "session" is needed here? One thing related to this though, in case an MSRP peer wants to = establish a new MSRP connection for e.g. filetransfer, should it assume = the "direction" properties of the existing MSRP session, or should the = endpoints do a full handshake on it? My proposal (which would require some text in MSRP) would be that the = directional proerties of the original MSRP connection are reused. I = would expect the circumstances in the network to remain constant, so = that the direction of the new MSRP session would likely turn out the = same as the original one. Regards, Aki >=20 >=20 > > =20 > > > >=20 > > > > We need text describing how and when an MSRP session=20 > > > transitions to a=20 > > > > new connection (or alternatively, someone can point me to=20 > > > the existing=20 > > > > text ;)) > > > >=20 > > >=20 > > > Why? It is not our lot to define user experience, only=20 > to define=20 > > > protocol behavior. Different implementers may have entirely=20 > > > different=20 > > > requirements here. We assume that some implementers=20 > will attempt to=20 > > > auto-resume sessions. > >=20 > > What do you mean by auto-resume? I am not talking about=20 > user experience here. I believe it is protocol behavior to=20 > describe what happens when a SEND times out, or a 5xx is=20 > received. Currently the behavior is that a client MAY=20 > retransmit, then quits the session. If the client may also=20 > reconnect and resend, then that needs to be included as well. >=20 > By auto-resume, I mean the idea that an endpoint might decide to go=20 > through the entire SDP handshake of creating a _new_ session=20 > (that is=20 > only connected with the old session in the user's head), and might=20 > attempt to resubmit any IMs that it had sent on the prior=20 > session for=20 > which it had not gotten a successful response. These would be new=20 > transactions, only coincidentally related to the failed transactions. >=20 > Again, I think some implementors might choose to do this,=20 > but we should=20 > no more recommend or forbid this than we should tell=20 > implementers what=20 > color to make their buttons. >=20 >=20 >=20 > > =20 > > > >> Relays shutting down gracefully, and timeouts on messages=20 > > > are simply > > > >> ways for the application to learn what it needs to=20 > > > achieve its ends. > > > >> Without some help, the application can't do this. > > > >=20 > > > >=20 > > > > Naturally, some help is also provided by the reliable=20 > > > connection the=20 > > > > MSRP runs on top of. > > > > > > >=20 > > > Certainly this is true for some cases. But it cannot=20 > guarantee to me=20 > > > that in the case where I send a message and get no response,=20 > > > that I know=20 > > > that the opposite peer did not receive it. > >=20 > > True. But it can give you a certain amount of more=20 > confidence that if a SEND times out, gets a 5xx, a=20 > retransmission will likely not give a better result, as=20 > opposed to if we were running MSRP over an unreliable transport. >=20 > Yes, this is true. THe discussion has not been so much about=20 > retrying a=20 > message on a particular session, as attempting to start a=20 > new session=20 > when the client thinks an old session has gone bad. >=20 > >=20 > > Regards, > > Aki > > =20 > > > >>> 2) Isn't this identical to a proxy server forwarding a=20 > > > MESSAGE (via > > > >>> TCP) and then shutting down? > > > >> > > > >> > > > >> SIP errs on the side of sending duplicates, and=20 > depends on the > > > >> recipient to recognize and discard them. Doing the=20 > same in MSRP is > > > >> the 4th choice in the vote. > > > >=20 > > > >=20 > > > > Right. I guess the difference in MSRP is that a TR-ID is=20 > > > only unique=20 > > > > within a connection. Does it need to be? Could option#4=20 > > > simply be to=20 > > > > make TR-ID globally unique? > > >=20 > > > That is what I had in mind _if_ we chose to pursue option 4.=20 > > > But it is=20 > > > more complex than just that--we would have to worry=20 > about how long a=20 > > > receivor had to remember what TR-IDs it had seen in the past. > > >=20 > > > >=20 > > > >>> I thought this is what we wanted to avoid with=20 > MSRP. If a relay > > > >>> also processes the SEND (i.e., receives it in=20 > entirety before > > > >>> forwarding it along on another connection), this bases a=20 > > > big burden > > > >>> on the relay when the SEND contains a 5GB movie. > > > >> > > > >> > > > >> A relay clearly does "process" a SEND, but I don't think=20 > > > we have made > > > >> any require that it receive the whole thing before=20 > > > forwarding it on. > > > >> If that is what you mean we wanted to avoid, then I=20 > think we have. > > > >> > > > >>> Why can't a relay simply peek at the first few=20 > bytes of message, > > > >>> see if it is not a BIND or VISIT, and forward it=20 > > > byte-by-byte over > > > >>> to the associated TCP connection. If there is=20 > trouble upstream, > > > >>> simply mirror that trouble downstream. > > > >> > > > >> > > > >> It can. It can also know that it is in the midst of=20 > forwarding a=20 > > > >> message. If it wants to shutdown before transmitting the=20 > > > last byte of > > > >> the message, it can send an error response indicating=20 > > > this is what > > > >> happened. > > > >=20 > > > >=20 > > > > Except that an MSRP client probably isn't expecting a=20 > > > response to a=20 > > > > request it is still in the process of sending? > > >=20 > > > We already have the ability for the peer endpoint to=20 > > > interrupt a message=20 > > > with an early response. It does clobber framing for the=20 > > > connection, and=20 > > > therefore requires the peer to also close the connection. > >=20 > > I didn't see this spelled out anywhere in the draft. > >=20 > > Regards, > > Aki > >=20 > > > >=20 > > > >>> This way, there are never messages in-transit over=20 > relay(s) (with > > > >>> the exception of a VISIT, which is always processed by a=20 > > > relay, but > > > >>> can also be forwarded to another target). > > > >> > > > >> > > > >> I don't see why this means there aren't messages in-transit. > > > >=20 > > > >=20 > > > > You're right. The problem does not go away. Even though=20 > > > there might be=20 > > > > fewer states the system could be in, the relay could still=20 > > > shut down=20 > > > > when the request is pending - and the problem would remain. > > > >=20 > > > > Basically, the reason I'm raising these questions is that=20 > > > at least for=20 > > > > the non-relay case, I would like things to be as simple as=20 > > > in IRC. That=20 > > > > is, to send a message, you write it to a buffer and flush=20 > > > it. Granted,=20 > > > > the presence of relays will make things a bit more=20 > > > complicated, but=20 > > > > still we should avoid adding complexity unless it's=20 > > > absolutely necessary. > > > >=20 > > > > Regards, > > > > Aki > > > >=20 > > > >> Paul > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 06:27:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20096 for ; Mon, 20 Oct 2003 06:27:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXFR-0003SQ-7L for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:26:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KAQmPs013284 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXFQ-0003SB-Fv for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 06:26:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20047; Mon, 20 Oct 2003 06:26:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXFL-0006So-00; Mon, 20 Oct 2003 06:26:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXFL-0006Sj-00; Mon, 20 Oct 2003 06:26:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXEg-0003IA-Re; Mon, 20 Oct 2003 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXEC-0003Cc-F3 for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20032 for ; Mon, 20 Oct 2003 06:25:20 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXE7-0006SJ-00 for simple@ietf.org; Mon, 20 Oct 2003 06:25:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXE6-0006S8-00 for simple@ietf.org; Mon, 20 Oct 2003 06:25:26 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KAPQX03624 for ; Mon, 20 Oct 2003 13:25:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 13:25:25 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 13:25:25 +0300 content-class: urn:content-classes:message Subject: RE: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A3@esebe013.ntc.nokia.com> Thread-Topic: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) Thread-Index: AcOUwWlMtFY7cuBMQ6ieFkc8jxCYhACMfpzQ To: Cc: , , X-OriginalArrivalTime: 20 Oct 2003 10:25:25.0852 (UTC) FILETIME=[79F0D9C0:01C396F4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:25:25 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 17 October, 2003 18:14 > To: Niemi Aki (NMP/Helsinki) > Cc: pkyzivat@cisco.com; rsparks@dynamicsoft.com; simple@ietf.org > Subject: MSRP: resuming sessions (was Re: [Simple] Chair=20 > call for group > opinion (was MSRP: Administrative shutdown of relays)) >=20 >=20 > aki.niemi@nokia.com wrote: >=20 > [...] >=20 > > Is this acceptable? A lot of the discussion so far has=20 > made the assumption that an MSRP client would reconnect and=20 > resend if there is a timeout, a 5xx, or the connection to=20 > the relay closes. That isn't the defined behavior, it=20 > actually goes against the defined behavior. > >=20 > > Bullet 5, Ch 7.4.3: > >=20 > > If the endpoint receives 5xx responses more than some threshold > > number of times in a row, it SHOULD assume the session has > > failed, and initiate tear-down via the signaling protocol. >=20 > Sure, it says the connection should be torn down. It does not say=20 > anything at all about whether a client should automatically=20 > attempt to=20 > create a new session or not. I don't think we should specify=20 > that sort=20 > of behavior one way or another. It does not seem to affect=20 > interoperability in any way. OK, then I misinterpreted you before. I thought by auto-resume, the MSRP = client would try to resume the *MSRP* session, meaning something like = establish a new TCP connection, do a VISIT, etc. Maybe some = clarification to the term "session" is needed here? One thing related to this though, in case an MSRP peer wants to = establish a new MSRP connection for e.g. filetransfer, should it assume = the "direction" properties of the existing MSRP session, or should the = endpoints do a full handshake on it? My proposal (which would require some text in MSRP) would be that the = directional proerties of the original MSRP connection are reused. I = would expect the circumstances in the network to remain constant, so = that the direction of the new MSRP session would likely turn out the = same as the original one. Regards, Aki >=20 >=20 > > =20 > > > >=20 > > > > We need text describing how and when an MSRP session=20 > > > transitions to a=20 > > > > new connection (or alternatively, someone can point me to=20 > > > the existing=20 > > > > text ;)) > > > >=20 > > >=20 > > > Why? It is not our lot to define user experience, only=20 > to define=20 > > > protocol behavior. Different implementers may have entirely=20 > > > different=20 > > > requirements here. We assume that some implementers=20 > will attempt to=20 > > > auto-resume sessions. > >=20 > > What do you mean by auto-resume? I am not talking about=20 > user experience here. I believe it is protocol behavior to=20 > describe what happens when a SEND times out, or a 5xx is=20 > received. Currently the behavior is that a client MAY=20 > retransmit, then quits the session. If the client may also=20 > reconnect and resend, then that needs to be included as well. >=20 > By auto-resume, I mean the idea that an endpoint might decide to go=20 > through the entire SDP handshake of creating a _new_ session=20 > (that is=20 > only connected with the old session in the user's head), and might=20 > attempt to resubmit any IMs that it had sent on the prior=20 > session for=20 > which it had not gotten a successful response. These would be new=20 > transactions, only coincidentally related to the failed transactions. >=20 > Again, I think some implementors might choose to do this,=20 > but we should=20 > no more recommend or forbid this than we should tell=20 > implementers what=20 > color to make their buttons. >=20 >=20 >=20 > > =20 > > > >> Relays shutting down gracefully, and timeouts on messages=20 > > > are simply > > > >> ways for the application to learn what it needs to=20 > > > achieve its ends. > > > >> Without some help, the application can't do this. > > > >=20 > > > >=20 > > > > Naturally, some help is also provided by the reliable=20 > > > connection the=20 > > > > MSRP runs on top of. > > > > > > >=20 > > > Certainly this is true for some cases. But it cannot=20 > guarantee to me=20 > > > that in the case where I send a message and get no response,=20 > > > that I know=20 > > > that the opposite peer did not receive it. > >=20 > > True. But it can give you a certain amount of more=20 > confidence that if a SEND times out, gets a 5xx, a=20 > retransmission will likely not give a better result, as=20 > opposed to if we were running MSRP over an unreliable transport. >=20 > Yes, this is true. THe discussion has not been so much about=20 > retrying a=20 > message on a particular session, as attempting to start a=20 > new session=20 > when the client thinks an old session has gone bad. >=20 > >=20 > > Regards, > > Aki > > =20 > > > >>> 2) Isn't this identical to a proxy server forwarding a=20 > > > MESSAGE (via > > > >>> TCP) and then shutting down? > > > >> > > > >> > > > >> SIP errs on the side of sending duplicates, and=20 > depends on the > > > >> recipient to recognize and discard them. Doing the=20 > same in MSRP is > > > >> the 4th choice in the vote. > > > >=20 > > > >=20 > > > > Right. I guess the difference in MSRP is that a TR-ID is=20 > > > only unique=20 > > > > within a connection. Does it need to be? Could option#4=20 > > > simply be to=20 > > > > make TR-ID globally unique? > > >=20 > > > That is what I had in mind _if_ we chose to pursue option 4.=20 > > > But it is=20 > > > more complex than just that--we would have to worry=20 > about how long a=20 > > > receivor had to remember what TR-IDs it had seen in the past. > > >=20 > > > >=20 > > > >>> I thought this is what we wanted to avoid with=20 > MSRP. If a relay > > > >>> also processes the SEND (i.e., receives it in=20 > entirety before > > > >>> forwarding it along on another connection), this bases a=20 > > > big burden > > > >>> on the relay when the SEND contains a 5GB movie. > > > >> > > > >> > > > >> A relay clearly does "process" a SEND, but I don't think=20 > > > we have made > > > >> any require that it receive the whole thing before=20 > > > forwarding it on. > > > >> If that is what you mean we wanted to avoid, then I=20 > think we have. > > > >> > > > >>> Why can't a relay simply peek at the first few=20 > bytes of message, > > > >>> see if it is not a BIND or VISIT, and forward it=20 > > > byte-by-byte over > > > >>> to the associated TCP connection. If there is=20 > trouble upstream, > > > >>> simply mirror that trouble downstream. > > > >> > > > >> > > > >> It can. It can also know that it is in the midst of=20 > forwarding a=20 > > > >> message. If it wants to shutdown before transmitting the=20 > > > last byte of > > > >> the message, it can send an error response indicating=20 > > > this is what > > > >> happened. > > > >=20 > > > >=20 > > > > Except that an MSRP client probably isn't expecting a=20 > > > response to a=20 > > > > request it is still in the process of sending? > > >=20 > > > We already have the ability for the peer endpoint to=20 > > > interrupt a message=20 > > > with an early response. It does clobber framing for the=20 > > > connection, and=20 > > > therefore requires the peer to also close the connection. > >=20 > > I didn't see this spelled out anywhere in the draft. > >=20 > > Regards, > > Aki > >=20 > > > >=20 > > > >>> This way, there are never messages in-transit over=20 > relay(s) (with > > > >>> the exception of a VISIT, which is always processed by a=20 > > > relay, but > > > >>> can also be forwarded to another target). > > > >> > > > >> > > > >> I don't see why this means there aren't messages in-transit. > > > >=20 > > > >=20 > > > > You're right. The problem does not go away. Even though=20 > > > there might be=20 > > > > fewer states the system could be in, the relay could still=20 > > > shut down=20 > > > > when the request is pending - and the problem would remain. > > > >=20 > > > > Basically, the reason I'm raising these questions is that=20 > > > at least for=20 > > > > the non-relay case, I would like things to be as simple as=20 > > > in IRC. That=20 > > > > is, to send a message, you write it to a buffer and flush=20 > > > it. Granted,=20 > > > > the presence of relays will make things a bit more=20 > > > complicated, but=20 > > > > still we should avoid adding complexity unless it's=20 > > > absolutely necessary. > > > >=20 > > > > Regards, > > > > Aki > > > >=20 > > > >> Paul > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 06:38:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20398; Mon, 20 Oct 2003 06:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXQP-0006ZU-00; Mon, 20 Oct 2003 06:38:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXQO-0006ZR-00; Mon, 20 Oct 2003 06:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXQI-00068W-Jl; Mon, 20 Oct 2003 06:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXQ5-000645-20 for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20389 for ; Mon, 20 Oct 2003 06:37:37 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXQ0-0006ZG-00 for simple@ietf.org; Mon, 20 Oct 2003 06:37:44 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXPz-0006Yx-00 for simple@ietf.org; Mon, 20 Oct 2003 06:37:44 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KAbHX17881 for ; Mon, 20 Oct 2003 13:37:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 13:37:17 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 13:37:17 +0300 content-class: urn:content-classes:message Subject: RE: [Simple] Comments on MSRP - multiparty message session support MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A4@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOU1SOWcLsI5y2hSBew5HgNqsu9CgCIKFdw To: Cc: X-OriginalArrivalTime: 20 Oct 2003 10:37:17.0117 (UTC) FILETIME=[21E346D0:01C396F6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:37:14 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 17 October, 2003 20:36 > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on MSRP - multiparty message session > support >=20 >=20 > We talked about how this could be done in a couple of ways.=20 > One was by=20 > simply having the mixer remember the identity associated with each=20 > connection. This would still not work, since there isn't a vehicle in the protocol = to transport this "asserted-identity" to the recipient endpoints. =20 > The mixer could also insist that all content be wrapped in=20 > message/cpim=20 > using our extension to the SDP format list negotiation. Which is fine, if all MSRP endpoints are required to support it. = Currently they aren't which potentially leaves a lot of MSRP clients = incapable of participating in message session conferences. Regards, Aki > Aki Niemi wrote: >=20 > > Hi All, > >=20 > > Since MSGFMT is no longer mandated (or is but only for=20 > CPIM gateways),=20 > > how would a participant know where a message is coming from in a=20 > > multiparty message session? > >=20 > > Also, when using MSRP in a conferencing system, the lack=20 > of To/From=20 > > prevents sending private messages efficiently within a multiparty=20 > > session using an MSRP mixer as a "router" for them. > >=20 > > So my question is this: what is the extensibility model=20 > for MSRP? For=20 > > example, would it be possible to later on add this multiparty=20 > > functionality as an extension, or would it be wise to think ahead=20 > > already now? > >=20 > > The draft includes some extensibility, e.g., for authentication=20 > > algorithms, but I didn't immediately find much about=20 > adding methods and=20 > > headers, and what to do with unknown headers. > >=20 > > Regards, > > Aki > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 06:38:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20429 for ; Mon, 20 Oct 2003 06:38:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXQU-0006Gm-TK for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:38:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KAcE7b024094 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 06:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXQU-0006GP-1x for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 06:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20398; Mon, 20 Oct 2003 06:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXQP-0006ZU-00; Mon, 20 Oct 2003 06:38:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXQO-0006ZR-00; Mon, 20 Oct 2003 06:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXQI-00068W-Jl; Mon, 20 Oct 2003 06:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXQ5-000645-20 for simple@optimus.ietf.org; Mon, 20 Oct 2003 06:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20389 for ; Mon, 20 Oct 2003 06:37:37 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXQ0-0006ZG-00 for simple@ietf.org; Mon, 20 Oct 2003 06:37:44 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXPz-0006Yx-00 for simple@ietf.org; Mon, 20 Oct 2003 06:37:44 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KAbHX17881 for ; Mon, 20 Oct 2003 13:37:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 13:37:17 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 13:37:17 +0300 content-class: urn:content-classes:message Subject: RE: [Simple] Comments on MSRP - multiparty message session support MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A4@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOU1SOWcLsI5y2hSBew5HgNqsu9CgCIKFdw To: Cc: X-OriginalArrivalTime: 20 Oct 2003 10:37:17.0117 (UTC) FILETIME=[21E346D0:01C396F6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:37:14 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 17 October, 2003 20:36 > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on MSRP - multiparty message session > support >=20 >=20 > We talked about how this could be done in a couple of ways.=20 > One was by=20 > simply having the mixer remember the identity associated with each=20 > connection. This would still not work, since there isn't a vehicle in the protocol = to transport this "asserted-identity" to the recipient endpoints. =20 > The mixer could also insist that all content be wrapped in=20 > message/cpim=20 > using our extension to the SDP format list negotiation. Which is fine, if all MSRP endpoints are required to support it. = Currently they aren't which potentially leaves a lot of MSRP clients = incapable of participating in message session conferences. Regards, Aki > Aki Niemi wrote: >=20 > > Hi All, > >=20 > > Since MSGFMT is no longer mandated (or is but only for=20 > CPIM gateways),=20 > > how would a participant know where a message is coming from in a=20 > > multiparty message session? > >=20 > > Also, when using MSRP in a conferencing system, the lack=20 > of To/From=20 > > prevents sending private messages efficiently within a multiparty=20 > > session using an MSRP mixer as a "router" for them. > >=20 > > So my question is this: what is the extensibility model=20 > for MSRP? For=20 > > example, would it be possible to later on add this multiparty=20 > > functionality as an extension, or would it be wise to think ahead=20 > > already now? > >=20 > > The draft includes some extensibility, e.g., for authentication=20 > > algorithms, but I didn't immediately find much about=20 > adding methods and=20 > > headers, and what to do with unknown headers. > >=20 > > Regards, > > Aki > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 07:01:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21027; Mon, 20 Oct 2003 07:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006ji-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006je-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnU-0003kO-Tz; Mon, 20 Oct 2003 07:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXml-0003YD-0I for simple@optimus.ietf.org; Mon, 20 Oct 2003 07:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20974 for ; Mon, 20 Oct 2003 07:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmg-0006ip-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmf-0006ii-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:09 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KB0tX20358 for ; Mon, 20 Oct 2003 14:00:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 14:00:55 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 14:00:54 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA10567; Mon, 20 Oct 2003 14:00:55 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KB0Igt011263; Mon, 20 Oct 2003 14:00:18 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KB0IRp011262; Mon, 20 Oct 2003 14:00:18 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Cc: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F902D71.9020507@dynamicsoft.com> (Ben Campbell's message of "Fri, 17 Oct 2003 12:57:05 -0500") References: <3F902D71.9020507@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 20 Oct 2003 11:00:54.0987 (UTC) FILETIME=[6F0111B0:01C396F9] Subject: [Simple] MSRP, CPIM and MIME content Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 14:00:18 +0300 Ben Campbell writes: >As far as mandating that we always use message/cpim, we did require that at >one time, but the wg consensus was for the protocol to allow any mime type. According to my recollection the WG consensus was to proceed with both campbell drafts as WG items (im-sessions aka msrp and cpimmsg-sessions). cpimmsg-sessions was killed because of comedia, I think. But they are your drafts, not mine. Again, it would be very beneficial and practically free to have CPIM container in SEND messages. Having that does not prevent anyone from sending any MIME type they want, they just have to add an empty CPIM container there. Receivers can ignore CPIM containers, unless there is a Requires header. As the MSRP stands now, we need to have a Content-Type with evil inner quoting rules (which need to be added to the ABNF). That would be fifth Content-Type header in our implementation, all those five headers having slightly different quoting rules. What about including MIME object in MSRP, just like a MIME object is included in CPIM? We could even save extra CR-LF and define that line starting with "Content-" will start a MIME object. BR, Pekka >> Hi, >> First, I've a problem with SDP usage by MSRP. >> The format parameters on SDP media line should be tokens, and "/" is not >> allowed within an SDP token. The token issue was discussed in MMUSIC wg, >> and the wg consensus was to keep definition of token as is (and fix the >> comment in sdp-new). >> So, the top-level media types should be put into an SDP attribute just >> like accept-wrapped-types. Example: >> m=message 9999 msrp/tcp * >> a=msrp-accept:message/cpim text/plain, text/html >> Alternatively, we could mandate that the MSRP content should always be >> Message/CPIM. The message/cpim itself mandates one header, Requires. So, >> instead of >> m=message 9999 msrp/tcp message/cpim text/plain text/html >> we would have something like this >> m=message 9999 msrp/tcp cpim >> a=msrp-accept: text/plain, text/html >> So, what would change at MSRP level? Currently we can have an MSRP message >> like this: >> MSRP xx SEND >> TR-ID: 123 >> Content-Type: text/plain >> Hi, I'm Alice! >> Instead of that, we could have a CPIM message with implied MIME type >> message/cpim (so, no Content-Type header in MSRP). Here we have CPIM >> message without any CPIM headers: >> MSRP xx SEND >> TR-ID: 123 >> Content-Type: text/plain >> Hi, I'm Alice! >> So, we pay two extra pairs of CR-LF for CPIM support. >> Sender can always include CPIM headers, like From and To, >> MSRP xx SEND >> TR-ID: 123 >> From: Alice >> To: Bob >> Content-Type: text/plain >> Hi, I'm Alice! >> but the recipient can safely ignore them. The only exception is Requires >> header. In order to properly process Requires, we need 420 Not >> Supported, too. Then it might be possible to extend MSRP using CPIM >> Requires header. Perhaps the supported or required extensions could be >> indicated as SDP >> attributes, too. >> What about signed CPIM messages? The could be sent inside another one >> MSRP xx SEND >> TR-ID: 123 >> My-Own-CPIM-Header: please see secured content >> Content-Type: multipart/signed; boundary=boundary; >> micalg=sha1; >> protocol=application/pkcs7-signature >> --boundary >> Content-Type: message/cpim >> From: Alice >> To: Bob >> Content-Type: text/plain >> Hi, I'm Alice! >> --boundary >> Content-Type: application/pkcs7-signature >> (lots-of-binary-signature-here) >> --boundary-- >> The real issue of CPIM is that it is just a wrapper around a MIME >> object. This is not a problem with most SIP implementations, as they >> already support MIME, but there may be some use of MSRP outside SIP? >> we could reuse CPIM header structure (quoting, line ending, etc) in >> MSRP, if we choose to always have a message/cpim wrapper. I don't mean >> that MSRP headers would be part of CPIM message, but that they reuse the >> Header ABNF from CPIM. >> --Pekka >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 07:01:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21028; Mon, 20 Oct 2003 07:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006jl-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006jf-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnV-0003l2-PC; Mon, 20 Oct 2003 07:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXn0-0003dJ-Mc for simple@optimus.ietf.org; Mon, 20 Oct 2003 07:01:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20994 for ; Mon, 20 Oct 2003 07:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmw-0006j3-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmq-0006ib-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:21 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KB0vX20397 for ; Mon, 20 Oct 2003 14:00:57 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 14:00:56 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 14:00:55 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA10572; Mon, 20 Oct 2003 14:00:56 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KAhCgt011227; Mon, 20 Oct 2003 13:43:12 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KAhBCn011226; Mon, 20 Oct 2003 13:43:11 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Cc: Pekka Pessi , simple@ietf.org Subject: Re: [Simple] MSRP, SDP (but no CPIM) X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F902D71.9020507@dynamicsoft.com> (Ben Campbell's message of "Fri, 17 Oct 2003 12:57:05 -0500") References: <3F902D71.9020507@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 20 Oct 2003 11:00:55.0627 (UTC) FILETIME=[6F62B9B0:01C396F9] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:43:11 +0300 Ben Campbell writes: >Someone mentioned the "/" issue to me in at the WG meeting. Was that you? We >have had some discussion between the authors on how to deal with this. I >plan to have something in the next update. I think your approach is as good >as anything we have come up with so far. Yes, that is me. We disscussed this in last IETF, and the top-level-accept was actually your idea. Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 07:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21087 for ; Mon, 20 Oct 2003 07:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnc-0003nU-3e for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 07:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KB287Y014594 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 07:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnb-0003nJ-UB for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 07:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21027; Mon, 20 Oct 2003 07:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006ji-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006je-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnU-0003kO-Tz; Mon, 20 Oct 2003 07:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXml-0003YD-0I for simple@optimus.ietf.org; Mon, 20 Oct 2003 07:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20974 for ; Mon, 20 Oct 2003 07:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmg-0006ip-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmf-0006ii-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:09 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KB0tX20358 for ; Mon, 20 Oct 2003 14:00:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 14:00:55 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 14:00:54 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA10567; Mon, 20 Oct 2003 14:00:55 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KB0Igt011263; Mon, 20 Oct 2003 14:00:18 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KB0IRp011262; Mon, 20 Oct 2003 14:00:18 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Cc: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F902D71.9020507@dynamicsoft.com> (Ben Campbell's message of "Fri, 17 Oct 2003 12:57:05 -0500") References: <3F902D71.9020507@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 20 Oct 2003 11:00:54.0987 (UTC) FILETIME=[6F0111B0:01C396F9] Subject: [Simple] MSRP, CPIM and MIME content Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 14:00:18 +0300 Ben Campbell writes: >As far as mandating that we always use message/cpim, we did require that at >one time, but the wg consensus was for the protocol to allow any mime type. According to my recollection the WG consensus was to proceed with both campbell drafts as WG items (im-sessions aka msrp and cpimmsg-sessions). cpimmsg-sessions was killed because of comedia, I think. But they are your drafts, not mine. Again, it would be very beneficial and practically free to have CPIM container in SEND messages. Having that does not prevent anyone from sending any MIME type they want, they just have to add an empty CPIM container there. Receivers can ignore CPIM containers, unless there is a Requires header. As the MSRP stands now, we need to have a Content-Type with evil inner quoting rules (which need to be added to the ABNF). That would be fifth Content-Type header in our implementation, all those five headers having slightly different quoting rules. What about including MIME object in MSRP, just like a MIME object is included in CPIM? We could even save extra CR-LF and define that line starting with "Content-" will start a MIME object. BR, Pekka >> Hi, >> First, I've a problem with SDP usage by MSRP. >> The format parameters on SDP media line should be tokens, and "/" is not >> allowed within an SDP token. The token issue was discussed in MMUSIC wg, >> and the wg consensus was to keep definition of token as is (and fix the >> comment in sdp-new). >> So, the top-level media types should be put into an SDP attribute just >> like accept-wrapped-types. Example: >> m=message 9999 msrp/tcp * >> a=msrp-accept:message/cpim text/plain, text/html >> Alternatively, we could mandate that the MSRP content should always be >> Message/CPIM. The message/cpim itself mandates one header, Requires. So, >> instead of >> m=message 9999 msrp/tcp message/cpim text/plain text/html >> we would have something like this >> m=message 9999 msrp/tcp cpim >> a=msrp-accept: text/plain, text/html >> So, what would change at MSRP level? Currently we can have an MSRP message >> like this: >> MSRP xx SEND >> TR-ID: 123 >> Content-Type: text/plain >> Hi, I'm Alice! >> Instead of that, we could have a CPIM message with implied MIME type >> message/cpim (so, no Content-Type header in MSRP). Here we have CPIM >> message without any CPIM headers: >> MSRP xx SEND >> TR-ID: 123 >> Content-Type: text/plain >> Hi, I'm Alice! >> So, we pay two extra pairs of CR-LF for CPIM support. >> Sender can always include CPIM headers, like From and To, >> MSRP xx SEND >> TR-ID: 123 >> From: Alice >> To: Bob >> Content-Type: text/plain >> Hi, I'm Alice! >> but the recipient can safely ignore them. The only exception is Requires >> header. In order to properly process Requires, we need 420 Not >> Supported, too. Then it might be possible to extend MSRP using CPIM >> Requires header. Perhaps the supported or required extensions could be >> indicated as SDP >> attributes, too. >> What about signed CPIM messages? The could be sent inside another one >> MSRP xx SEND >> TR-ID: 123 >> My-Own-CPIM-Header: please see secured content >> Content-Type: multipart/signed; boundary=boundary; >> micalg=sha1; >> protocol=application/pkcs7-signature >> --boundary >> Content-Type: message/cpim >> From: Alice >> To: Bob >> Content-Type: text/plain >> Hi, I'm Alice! >> --boundary >> Content-Type: application/pkcs7-signature >> (lots-of-binary-signature-here) >> --boundary-- >> The real issue of CPIM is that it is just a wrapper around a MIME >> object. This is not a problem with most SIP implementations, as they >> already support MIME, but there may be some use of MSRP outside SIP? >> we could reuse CPIM header structure (quoting, line ending, etc) in >> MSRP, if we choose to always have a message/cpim wrapper. I don't mean >> that MSRP headers would be part of CPIM message, but that they reuse the >> Header ABNF from CPIM. >> --Pekka >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 07:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21088 for ; Mon, 20 Oct 2003 07:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnc-0003o7-Hy for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 07:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KB28kl014627 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 07:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnc-0003ni-6s for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 07:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21028; Mon, 20 Oct 2003 07:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006jl-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABXnW-0006jf-00; Mon, 20 Oct 2003 07:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXnV-0003l2-PC; Mon, 20 Oct 2003 07:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXn0-0003dJ-Mc for simple@optimus.ietf.org; Mon, 20 Oct 2003 07:01:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20994 for ; Mon, 20 Oct 2003 07:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmw-0006j3-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABXmq-0006ib-00 for simple@ietf.org; Mon, 20 Oct 2003 07:01:21 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KB0vX20397 for ; Mon, 20 Oct 2003 14:00:57 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 14:00:56 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 14:00:55 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA10572; Mon, 20 Oct 2003 14:00:56 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KAhCgt011227; Mon, 20 Oct 2003 13:43:12 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KAhBCn011226; Mon, 20 Oct 2003 13:43:11 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Cc: Pekka Pessi , simple@ietf.org Subject: Re: [Simple] MSRP, SDP (but no CPIM) X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F902D71.9020507@dynamicsoft.com> (Ben Campbell's message of "Fri, 17 Oct 2003 12:57:05 -0500") References: <3F902D71.9020507@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 20 Oct 2003 11:00:55.0627 (UTC) FILETIME=[6F62B9B0:01C396F9] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:43:11 +0300 Ben Campbell writes: >Someone mentioned the "/" issue to me in at the WG meeting. Was that you? We >have had some discussion between the authors on how to deal with this. I >plan to have something in the next update. I think your approach is as good >as anything we have come up with so far. Yes, that is me. We disscussed this in last IETF, and the top-level-accept was actually your idea. Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 09:28:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25372; Mon, 20 Oct 2003 09:28:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa5Z-0000BS-00; Mon, 20 Oct 2003 09:28:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABa5Z-0000BP-00; Mon, 20 Oct 2003 09:28:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa4m-0001gR-Tq; Mon, 20 Oct 2003 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa4j-0001g0-BY for simple@optimus.ietf.org; Mon, 20 Oct 2003 09:27:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25338 for ; Mon, 20 Oct 2003 09:27:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa4h-0000A6-00 for simple@ietf.org; Mon, 20 Oct 2003 09:27:55 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABa4g-00009o-00 for simple@ietf.org; Mon, 20 Oct 2003 09:27:54 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KDR4F8089002; Mon, 20 Oct 2003 08:27:15 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F93E299.80402@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: simple@ietf.org References: <3F902D71.9020507@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: MSRP, CPIM and MIME content Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 08:26:49 -0500 Content-Transfer-Encoding: 7bit Pekka Pessi wrote: > Ben Campbell writes: > >>As far as mandating that we always use message/cpim, we did require that at >>one time, but the wg consensus was for the protocol to allow any mime type. > > > According to my recollection the WG consensus was to proceed > with both campbell drafts as WG items (im-sessions aka msrp and > cpimmsg-sessions). cpimmsg-sessions was killed because of > comedia, I think. But they are your drafts, not mine. > > Again, it would be very beneficial and practically free to have > CPIM container in SEND messages. Having that does not prevent > anyone from sending any MIME type they want, they just have to > add an empty CPIM container there. Receivers can ignore CPIM > containers, unless there is a Requires header. The current draft allows message/cpim, and provides a way that either endpoint may insist on it. But considering that our preferred use-case is end-to-end with no intervening relays, and that endpoints may insist on using TLS, requiring all sessions to use mesage/cpim seems very heavy weight. > > As the MSRP stands now, we need to have a Content-Type with evil > inner quoting rules (which need to be added to the ABNF). That > would be fifth Content-Type header in our implementation, all > those five headers having slightly different quoting rules. > Can you elaborate on the required quoting rules? > What about including MIME object in MSRP, just like a MIME > object is included in CPIM? We could even save extra CR-LF and > define that line starting with "Content-" will start a MIME > object. We already support including any MIME object. We do still require the crlf. I am not sure saving the two bytes is worth the change. > > BR, > Pekka > > >>>Hi, >>>First, I've a problem with SDP usage by MSRP. >>>The format parameters on SDP media line should be tokens, and "/" is not >>>allowed within an SDP token. The token issue was discussed in MMUSIC wg, >>>and the wg consensus was to keep definition of token as is (and fix the >>>comment in sdp-new). >>>So, the top-level media types should be put into an SDP attribute just >>>like accept-wrapped-types. Example: >>> m=message 9999 msrp/tcp * >>> a=msrp-accept:message/cpim text/plain, text/html >>>Alternatively, we could mandate that the MSRP content should always be >>>Message/CPIM. The message/cpim itself mandates one header, Requires. So, >>>instead of >>> m=message 9999 msrp/tcp message/cpim text/plain text/html >>>we would have something like this >>> m=message 9999 msrp/tcp cpim >>> a=msrp-accept: text/plain, text/html >>>So, what would change at MSRP level? Currently we can have an MSRP message >>>like this: >>> MSRP xx SEND >>> TR-ID: 123 >>> Content-Type: text/plain >>> Hi, I'm Alice! >>>Instead of that, we could have a CPIM message with implied MIME type >>>message/cpim (so, no Content-Type header in MSRP). Here we have CPIM >>>message without any CPIM headers: >>> MSRP xx SEND >>> TR-ID: 123 >>> Content-Type: text/plain >>> Hi, I'm Alice! >>>So, we pay two extra pairs of CR-LF for CPIM support. >>>Sender can always include CPIM headers, like From and To, >>> MSRP xx SEND >>> TR-ID: 123 >>> From: Alice >>> To: Bob >>> Content-Type: text/plain >>> Hi, I'm Alice! >>> but the recipient can safely ignore them. The only exception is Requires >>>header. In order to properly process Requires, we need 420 Not >>>Supported, too. Then it might be possible to extend MSRP using CPIM >>>Requires header. Perhaps the supported or required extensions could be >>>indicated as SDP >>>attributes, too. >>>What about signed CPIM messages? The could be sent inside another one >>> MSRP xx SEND >>> TR-ID: 123 >>> My-Own-CPIM-Header: please see secured content >>> Content-Type: multipart/signed; boundary=boundary; >>> micalg=sha1; >>> protocol=application/pkcs7-signature >>> --boundary >>> Content-Type: message/cpim >>> From: Alice >>> To: Bob >>> Content-Type: text/plain >>> Hi, I'm Alice! >>> --boundary >>> Content-Type: application/pkcs7-signature >>> (lots-of-binary-signature-here) >>> --boundary-- >>>The real issue of CPIM is that it is just a wrapper around a MIME >>>object. This is not a problem with most SIP implementations, as they >>>already support MIME, but there may be some use of MSRP outside SIP? >>>we could reuse CPIM header structure (quoting, line ending, etc) in >>>MSRP, if we choose to always have a message/cpim wrapper. I don't mean >>>that MSRP headers would be part of CPIM message, but that they reuse the >>>Header ABNF from CPIM. >>>--Pekka >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple > > > > >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 09:29:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25396 for ; Mon, 20 Oct 2003 09:29:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa5c-0001zl-6t for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 09:28:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KDSq3R007666 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 09:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa5c-0001zZ-2i for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 09:28:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25372; Mon, 20 Oct 2003 09:28:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa5Z-0000BS-00; Mon, 20 Oct 2003 09:28:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABa5Z-0000BP-00; Mon, 20 Oct 2003 09:28:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa4m-0001gR-Tq; Mon, 20 Oct 2003 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa4j-0001g0-BY for simple@optimus.ietf.org; Mon, 20 Oct 2003 09:27:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25338 for ; Mon, 20 Oct 2003 09:27:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa4h-0000A6-00 for simple@ietf.org; Mon, 20 Oct 2003 09:27:55 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABa4g-00009o-00 for simple@ietf.org; Mon, 20 Oct 2003 09:27:54 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KDR4F8089002; Mon, 20 Oct 2003 08:27:15 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F93E299.80402@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: simple@ietf.org References: <3F902D71.9020507@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: MSRP, CPIM and MIME content Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 08:26:49 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Pessi wrote: > Ben Campbell writes: > >>As far as mandating that we always use message/cpim, we did require that at >>one time, but the wg consensus was for the protocol to allow any mime type. > > > According to my recollection the WG consensus was to proceed > with both campbell drafts as WG items (im-sessions aka msrp and > cpimmsg-sessions). cpimmsg-sessions was killed because of > comedia, I think. But they are your drafts, not mine. > > Again, it would be very beneficial and practically free to have > CPIM container in SEND messages. Having that does not prevent > anyone from sending any MIME type they want, they just have to > add an empty CPIM container there. Receivers can ignore CPIM > containers, unless there is a Requires header. The current draft allows message/cpim, and provides a way that either endpoint may insist on it. But considering that our preferred use-case is end-to-end with no intervening relays, and that endpoints may insist on using TLS, requiring all sessions to use mesage/cpim seems very heavy weight. > > As the MSRP stands now, we need to have a Content-Type with evil > inner quoting rules (which need to be added to the ABNF). That > would be fifth Content-Type header in our implementation, all > those five headers having slightly different quoting rules. > Can you elaborate on the required quoting rules? > What about including MIME object in MSRP, just like a MIME > object is included in CPIM? We could even save extra CR-LF and > define that line starting with "Content-" will start a MIME > object. We already support including any MIME object. We do still require the crlf. I am not sure saving the two bytes is worth the change. > > BR, > Pekka > > >>>Hi, >>>First, I've a problem with SDP usage by MSRP. >>>The format parameters on SDP media line should be tokens, and "/" is not >>>allowed within an SDP token. The token issue was discussed in MMUSIC wg, >>>and the wg consensus was to keep definition of token as is (and fix the >>>comment in sdp-new). >>>So, the top-level media types should be put into an SDP attribute just >>>like accept-wrapped-types. Example: >>> m=message 9999 msrp/tcp * >>> a=msrp-accept:message/cpim text/plain, text/html >>>Alternatively, we could mandate that the MSRP content should always be >>>Message/CPIM. The message/cpim itself mandates one header, Requires. So, >>>instead of >>> m=message 9999 msrp/tcp message/cpim text/plain text/html >>>we would have something like this >>> m=message 9999 msrp/tcp cpim >>> a=msrp-accept: text/plain, text/html >>>So, what would change at MSRP level? Currently we can have an MSRP message >>>like this: >>> MSRP xx SEND >>> TR-ID: 123 >>> Content-Type: text/plain >>> Hi, I'm Alice! >>>Instead of that, we could have a CPIM message with implied MIME type >>>message/cpim (so, no Content-Type header in MSRP). Here we have CPIM >>>message without any CPIM headers: >>> MSRP xx SEND >>> TR-ID: 123 >>> Content-Type: text/plain >>> Hi, I'm Alice! >>>So, we pay two extra pairs of CR-LF for CPIM support. >>>Sender can always include CPIM headers, like From and To, >>> MSRP xx SEND >>> TR-ID: 123 >>> From: Alice >>> To: Bob >>> Content-Type: text/plain >>> Hi, I'm Alice! >>> but the recipient can safely ignore them. The only exception is Requires >>>header. In order to properly process Requires, we need 420 Not >>>Supported, too. Then it might be possible to extend MSRP using CPIM >>>Requires header. Perhaps the supported or required extensions could be >>>indicated as SDP >>>attributes, too. >>>What about signed CPIM messages? The could be sent inside another one >>> MSRP xx SEND >>> TR-ID: 123 >>> My-Own-CPIM-Header: please see secured content >>> Content-Type: multipart/signed; boundary=boundary; >>> micalg=sha1; >>> protocol=application/pkcs7-signature >>> --boundary >>> Content-Type: message/cpim >>> From: Alice >>> To: Bob >>> Content-Type: text/plain >>> Hi, I'm Alice! >>> --boundary >>> Content-Type: application/pkcs7-signature >>> (lots-of-binary-signature-here) >>> --boundary-- >>>The real issue of CPIM is that it is just a wrapper around a MIME >>>object. This is not a problem with most SIP implementations, as they >>>already support MIME, but there may be some use of MSRP outside SIP? >>>we could reuse CPIM header structure (quoting, line ending, etc) in >>>MSRP, if we choose to always have a message/cpim wrapper. I don't mean >>>that MSRP headers would be part of CPIM message, but that they reuse the >>>Header ABNF from CPIM. >>>--Pekka >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple > > > > >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 09:31:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25493; Mon, 20 Oct 2003 09:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa8j-0000DC-00; Mon, 20 Oct 2003 09:32:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABa8j-0000D9-00; Mon, 20 Oct 2003 09:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa8f-0002ya-RO; Mon, 20 Oct 2003 09:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa8P-0002tD-LS for simple@optimus.ietf.org; Mon, 20 Oct 2003 09:31:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25479 for ; Mon, 20 Oct 2003 09:31:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa8N-0000Cl-00 for simple@ietf.org; Mon, 20 Oct 2003 09:31:43 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABa8M-0000Ch-00 for simple@ietf.org; Mon, 20 Oct 2003 09:31:43 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KDVfF8089546; Mon, 20 Oct 2003 08:31:41 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F93E3AE.1030408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A4@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A4@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 08:31:26 -0500 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 17 October, 2003 20:36 > > To: Niemi Aki (NMP/Helsinki) > > Cc: simple@ietf.org > > Subject: Re: [Simple] Comments on MSRP - multiparty message session > > support > > > > > > We talked about how this could be done in a couple of ways. > > One was by > > simply having the mixer remember the identity associated with each > > connection. > > This would still not work, since there isn't a vehicle in the protocol to transport this "asserted-identity" to the recipient endpoints. > > > The mixer could also insist that all content be wrapped in > > message/cpim > > using our extension to the SDP format list negotiation. > > Which is fine, if all MSRP endpoints are required to support it. Currently they aren't which potentially leaves a lot of MSRP clients incapable of participating in message session conferences. I am not opposed to requiring support for this. In retrospect, I think we intended to do that and it just didn't make it in. > > Regards, > Aki > > > Aki Niemi wrote: > > > > > Hi All, > > > > > > Since MSGFMT is no longer mandated (or is but only for > > CPIM gateways), > > > how would a participant know where a message is coming from in a > > > multiparty message session? > > > > > > Also, when using MSRP in a conferencing system, the lack > > of To/From > > > prevents sending private messages efficiently within a multiparty > > > session using an MSRP mixer as a "router" for them. > > > > > > So my question is this: what is the extensibility model > > for MSRP? For > > > example, would it be possible to later on add this multiparty > > > functionality as an extension, or would it be wise to think ahead > > > already now? > > > > > > The draft includes some extensibility, e.g., for authentication > > > algorithms, but I didn't immediately find much about > > adding methods and > > > headers, and what to do with unknown headers. > > > > > > Regards, > > > Aki > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 09:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25524 for ; Mon, 20 Oct 2003 09:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa8m-00031P-9K for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 09:32:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KDW8ZK011609 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 09:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa8m-00031A-5p for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 09:32:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25493; Mon, 20 Oct 2003 09:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa8j-0000DC-00; Mon, 20 Oct 2003 09:32:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABa8j-0000D9-00; Mon, 20 Oct 2003 09:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa8f-0002ya-RO; Mon, 20 Oct 2003 09:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABa8P-0002tD-LS for simple@optimus.ietf.org; Mon, 20 Oct 2003 09:31:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25479 for ; Mon, 20 Oct 2003 09:31:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABa8N-0000Cl-00 for simple@ietf.org; Mon, 20 Oct 2003 09:31:43 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABa8M-0000Ch-00 for simple@ietf.org; Mon, 20 Oct 2003 09:31:43 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KDVfF8089546; Mon, 20 Oct 2003 08:31:41 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F93E3AE.1030408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A4@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A4@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 08:31:26 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 17 October, 2003 20:36 > > To: Niemi Aki (NMP/Helsinki) > > Cc: simple@ietf.org > > Subject: Re: [Simple] Comments on MSRP - multiparty message session > > support > > > > > > We talked about how this could be done in a couple of ways. > > One was by > > simply having the mixer remember the identity associated with each > > connection. > > This would still not work, since there isn't a vehicle in the protocol to transport this "asserted-identity" to the recipient endpoints. > > > The mixer could also insist that all content be wrapped in > > message/cpim > > using our extension to the SDP format list negotiation. > > Which is fine, if all MSRP endpoints are required to support it. Currently they aren't which potentially leaves a lot of MSRP clients incapable of participating in message session conferences. I am not opposed to requiring support for this. In retrospect, I think we intended to do that and it just didn't make it in. > > Regards, > Aki > > > Aki Niemi wrote: > > > > > Hi All, > > > > > > Since MSGFMT is no longer mandated (or is but only for > > CPIM gateways), > > > how would a participant know where a message is coming from in a > > > multiparty message session? > > > > > > Also, when using MSRP in a conferencing system, the lack > > of To/From > > > prevents sending private messages efficiently within a multiparty > > > session using an MSRP mixer as a "router" for them. > > > > > > So my question is this: what is the extensibility model > > for MSRP? For > > > example, would it be possible to later on add this multiparty > > > functionality as an extension, or would it be wise to think ahead > > > already now? > > > > > > The draft includes some extensibility, e.g., for authentication > > > algorithms, but I didn't immediately find much about > > adding methods and > > > headers, and what to do with unknown headers. > > > > > > Regards, > > > Aki > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 12:17:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02397; Mon, 20 Oct 2003 12:17:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcih-0001vf-00; Mon, 20 Oct 2003 12:17:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABcih-0001vc-00; Mon, 20 Oct 2003 12:17:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABciL-0003lJ-8A; Mon, 20 Oct 2003 12:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABchb-0003XT-MK for simple@optimus.ietf.org; Mon, 20 Oct 2003 12:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02330 for ; Mon, 20 Oct 2003 12:16:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcha-0001uo-00 for simple@ietf.org; Mon, 20 Oct 2003 12:16:14 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABchZ-0001ul-00 for simple@ietf.org; Mon, 20 Oct 2003 12:16:13 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KGGCX00420 for ; Mon, 20 Oct 2003 19:16:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 19:16:10 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 19:15:29 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id TAA14304; Mon, 20 Oct 2003 19:15:29 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KGFNqs015026; Mon, 20 Oct 2003 19:15:23 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KGFN12015025; Mon, 20 Oct 2003 19:15:23 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Cc: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F93E299.80402@dynamicsoft.com> (Ben Campbell's message of "Mon, 20 Oct 2003 08:26:49 -0500") References: <3F902D71.9020507@dynamicsoft.com> <3F93E299.80402@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 20 Oct 2003 16:15:29.0052 (UTC) FILETIME=[60D2D5C0:01C39725] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-x4.nokia.com id h9KGGCX00420 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Re: MSRP, CPIM and MIME content Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 19:15:22 +0300 Content-Transfer-Encoding: quoted-printable Ben Campbell writes: >The current draft allows message/cpim, and provides a way that either >endpoint may insist on it. But considering that our preferred use-case i= s >end-to-end with no intervening relays, and that endpoints may insist on >using TLS, requiring all sessions to use mesage/cpim seems very heavy we= ight. Now I *think* I understand your point. Because we can not know if there is a relay, and if end-to-end security is required, impp-im mandates us to use S/MIME? But the same document mandates us to use message/cpim is end-to-end security is required. If you just use message/cpim it does not mean that you have to us S/MIME. >> As the MSRP stands now, we need to have a Content-Type with evil >> inner quoting rules (which need to be added to the ABNF). That >> would be fifth Content-Type header in our implementation, all >> those five headers having slightly different quoting rules. >Can you elaborate on the required quoting rules?=20 I'm sorry, I've probably have been working a bit too closely with evil MIME things lately. So, MSRP Content-Type is defined as=20 "Content-Type" ":" quoted-string Which definition of quoted-string you use, RFC 2046 / RFC 2822, HTTP, SIP, CPIM? Your own? On a gateway, can we map any Content-Type header to an MSRP Content-Type and vice versa? IOW, what we do with an incoming header Content-Type: multipart/mixed; boundary=3D"asdfjkl=F6"; description=3D"Th= is is a \"MIME\" message." ?? >> What about including MIME object in MSRP, just like a MIME >> object is included in CPIM? We could even save extra CR-LF and >> define that line starting with "Content-" will start a MIME >> object. >We already support including any MIME object.=20 I was trying to say that we should include MIME objects in MSRP like Message/CPIM does. In message/cpim MIME headers are separated from the CPIM headers by an empty line. But in any case, currently MSRP does not have MIME-Version header, which is a MUST thing by RFC 2045. Pekka >>>>Hi, >>>>First, I've a problem with SDP usage by MSRP. >>>>The format parameters on SDP media line should be tokens, and "/" is = not >>>>allowed within an SDP token. The token issue was discussed in MMUSIC = wg, >>>>and the wg consensus was to keep definition of token as is (and fix t= he >>>>comment in sdp-new). >>>>So, the top-level media types should be put into an SDP attribute jus= t >>>>like accept-wrapped-types. Example: >>>> m=3Dmessage 9999 msrp/tcp * >>>> a=3Dmsrp-accept:message/cpim text/plain, text/html >>>>Alternatively, we could mandate that the MSRP content should always b= e >>>>Message/CPIM. The message/cpim itself mandates one header, Requires. = So, >>>>instead of >>>> m=3Dmessage 9999 msrp/tcp message/cpim text/plain text/html >>>>we would have something like this >>>> m=3Dmessage 9999 msrp/tcp cpim >>>> a=3Dmsrp-accept: text/plain, text/html >>>>So, what would change at MSRP level? Currently we can have an MSRP me= ssage >>>>like this: >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>>Instead of that, we could have a CPIM message with implied MIME type >>>>message/cpim (so, no Content-Type header in MSRP). Here we have CPIM >>>>message without any CPIM headers: >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>>So, we pay two extra pairs of CR-LF for CPIM support. >>>>Sender can always include CPIM headers, like From and To, >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> From: Alice >>>> To: Bob >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>> but the recipient can safely ignore them. The only exception is Requ= ires >>>>header. In order to properly process Requires, we need 420 Not >>>>Supported, too. Then it might be possible to extend MSRP using CPIM >>>>Requires header. Perhaps the supported or required extensions could b= e >>>>indicated as SDP >>>>attributes, too. >>>>What about signed CPIM messages? The could be sent inside another one >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> My-Own-CPIM-Header: please see secured content >>>> Content-Type: multipart/signed; boundary=3Dboundary; >>>> micalg=3Dsha1; >>>> protocol=3Dapplication/pkcs7-signature >>>> --boundary >>>> Content-Type: message/cpim >>>> From: Alice >>>> To: Bob >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>> --boundary >>>> Content-Type: application/pkcs7-signature >>>> (lots-of-binary-signature-here) >>>> --boundary-- >>>>The real issue of CPIM is that it is just a wrapper around a MIME >>>>object. This is not a problem with most SIP implementations, as they >>>>already support MIME, but there may be some use of MSRP outside SIP? >>>>we could reuse CPIM header structure (quoting, line ending, etc) in >>>>MSRP, if we choose to always have a message/cpim wrapper. I don't mea= n >>>>that MSRP headers would be part of CPIM message, but that they reuse = the >>>>Header ABNF from CPIM. >>>>--Pekka >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 12:17:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02467 for ; Mon, 20 Oct 2003 12:17:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcij-0003ta-Kq for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 12:17:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KGHPQn014970 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 12:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcij-0003tJ-HB for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 12:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02397; Mon, 20 Oct 2003 12:17:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcih-0001vf-00; Mon, 20 Oct 2003 12:17:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABcih-0001vc-00; Mon, 20 Oct 2003 12:17:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABciL-0003lJ-8A; Mon, 20 Oct 2003 12:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABchb-0003XT-MK for simple@optimus.ietf.org; Mon, 20 Oct 2003 12:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02330 for ; Mon, 20 Oct 2003 12:16:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcha-0001uo-00 for simple@ietf.org; Mon, 20 Oct 2003 12:16:14 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABchZ-0001ul-00 for simple@ietf.org; Mon, 20 Oct 2003 12:16:13 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KGGCX00420 for ; Mon, 20 Oct 2003 19:16:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 19:16:10 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 19:15:29 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id TAA14304; Mon, 20 Oct 2003 19:15:29 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9KGFNqs015026; Mon, 20 Oct 2003 19:15:23 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9KGFN12015025; Mon, 20 Oct 2003 19:15:23 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Cc: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F93E299.80402@dynamicsoft.com> (Ben Campbell's message of "Mon, 20 Oct 2003 08:26:49 -0500") References: <3F902D71.9020507@dynamicsoft.com> <3F93E299.80402@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 20 Oct 2003 16:15:29.0052 (UTC) FILETIME=[60D2D5C0:01C39725] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-x4.nokia.com id h9KGGCX00420 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Re: MSRP, CPIM and MIME content Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 19:15:22 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ben Campbell writes: >The current draft allows message/cpim, and provides a way that either >endpoint may insist on it. But considering that our preferred use-case i= s >end-to-end with no intervening relays, and that endpoints may insist on >using TLS, requiring all sessions to use mesage/cpim seems very heavy we= ight. Now I *think* I understand your point. Because we can not know if there is a relay, and if end-to-end security is required, impp-im mandates us to use S/MIME? But the same document mandates us to use message/cpim is end-to-end security is required. If you just use message/cpim it does not mean that you have to us S/MIME. >> As the MSRP stands now, we need to have a Content-Type with evil >> inner quoting rules (which need to be added to the ABNF). That >> would be fifth Content-Type header in our implementation, all >> those five headers having slightly different quoting rules. >Can you elaborate on the required quoting rules?=20 I'm sorry, I've probably have been working a bit too closely with evil MIME things lately. So, MSRP Content-Type is defined as=20 "Content-Type" ":" quoted-string Which definition of quoted-string you use, RFC 2046 / RFC 2822, HTTP, SIP, CPIM? Your own? On a gateway, can we map any Content-Type header to an MSRP Content-Type and vice versa? IOW, what we do with an incoming header Content-Type: multipart/mixed; boundary=3D"asdfjkl=F6"; description=3D"Th= is is a \"MIME\" message." ?? >> What about including MIME object in MSRP, just like a MIME >> object is included in CPIM? We could even save extra CR-LF and >> define that line starting with "Content-" will start a MIME >> object. >We already support including any MIME object.=20 I was trying to say that we should include MIME objects in MSRP like Message/CPIM does. In message/cpim MIME headers are separated from the CPIM headers by an empty line. But in any case, currently MSRP does not have MIME-Version header, which is a MUST thing by RFC 2045. Pekka >>>>Hi, >>>>First, I've a problem with SDP usage by MSRP. >>>>The format parameters on SDP media line should be tokens, and "/" is = not >>>>allowed within an SDP token. The token issue was discussed in MMUSIC = wg, >>>>and the wg consensus was to keep definition of token as is (and fix t= he >>>>comment in sdp-new). >>>>So, the top-level media types should be put into an SDP attribute jus= t >>>>like accept-wrapped-types. Example: >>>> m=3Dmessage 9999 msrp/tcp * >>>> a=3Dmsrp-accept:message/cpim text/plain, text/html >>>>Alternatively, we could mandate that the MSRP content should always b= e >>>>Message/CPIM. The message/cpim itself mandates one header, Requires. = So, >>>>instead of >>>> m=3Dmessage 9999 msrp/tcp message/cpim text/plain text/html >>>>we would have something like this >>>> m=3Dmessage 9999 msrp/tcp cpim >>>> a=3Dmsrp-accept: text/plain, text/html >>>>So, what would change at MSRP level? Currently we can have an MSRP me= ssage >>>>like this: >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>>Instead of that, we could have a CPIM message with implied MIME type >>>>message/cpim (so, no Content-Type header in MSRP). Here we have CPIM >>>>message without any CPIM headers: >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>>So, we pay two extra pairs of CR-LF for CPIM support. >>>>Sender can always include CPIM headers, like From and To, >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> From: Alice >>>> To: Bob >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>> but the recipient can safely ignore them. The only exception is Requ= ires >>>>header. In order to properly process Requires, we need 420 Not >>>>Supported, too. Then it might be possible to extend MSRP using CPIM >>>>Requires header. Perhaps the supported or required extensions could b= e >>>>indicated as SDP >>>>attributes, too. >>>>What about signed CPIM messages? The could be sent inside another one >>>> MSRP xx SEND >>>> TR-ID: 123 >>>> My-Own-CPIM-Header: please see secured content >>>> Content-Type: multipart/signed; boundary=3Dboundary; >>>> micalg=3Dsha1; >>>> protocol=3Dapplication/pkcs7-signature >>>> --boundary >>>> Content-Type: message/cpim >>>> From: Alice >>>> To: Bob >>>> Content-Type: text/plain >>>> Hi, I'm Alice! >>>> --boundary >>>> Content-Type: application/pkcs7-signature >>>> (lots-of-binary-signature-here) >>>> --boundary-- >>>>The real issue of CPIM is that it is just a wrapper around a MIME >>>>object. This is not a problem with most SIP implementations, as they >>>>already support MIME, but there may be some use of MSRP outside SIP? >>>>we could reuse CPIM header structure (quoting, line ending, etc) in >>>>MSRP, if we choose to always have a message/cpim wrapper. I don't mea= n >>>>that MSRP headers would be part of CPIM message, but that they reuse = the >>>>Header ABNF from CPIM. >>>>--Pekka >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 12:58:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03684; Mon, 20 Oct 2003 12:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdMG-0002H0-00; Mon, 20 Oct 2003 12:58:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdM6-0002Gp-00; Mon, 20 Oct 2003 12:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdM0-0004TH-VH; Mon, 20 Oct 2003 12:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdL3-0004KI-8G for simple@optimus.ietf.org; Mon, 20 Oct 2003 12:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03624 for ; Mon, 20 Oct 2003 12:56:50 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdL1-0002GR-00 for simple@ietf.org; Mon, 20 Oct 2003 12:56:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABdL0-0002GO-00 for simple@ietf.org; Mon, 20 Oct 2003 12:56:58 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KGuvd10080 for ; Mon, 20 Oct 2003 19:56:57 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 19:56:57 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 19:56:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] What can you do with a list? Message-ID: Thread-Topic: [Simple] What can you do with a list? Thread-Index: AcOWhLcPiE63xllyQSyE+BSDt5nxnwApDJJQ To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 16:56:57.0362 (UTC) FILETIME=[2BF8CF20:01C3972B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 19:56:56 +0300 Content-Transfer-Encoding: quoted-printable Hi, I'm also happy to go for option (1) now, and leave (2) for an extension. Having said that, I think we should do the support for MESSAGE request = to the list urgently too, since there are many products around doing = such things already, and it would be nice to get some interoperability = too. XCAP part is rather obvious, but I belive some discussion is needed = about the requirements on the SIP side. At least this comes to mind: - Do we want to support the reporting on success/failure of the = "exploder" to deliver the request to each destination on the list?=20 About and conferencing: From the user's point of view I = think it is clear that the same list should be usable for initiating = conferences too. But this could be done by issuing a CPCP command (based = on eventual XCON WG output) that is able to reference the HTTP URI of = the list too. I think the assumption in XCON is that CPCP would have = this kind of functionality (i.e. mass-invitation). Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 20 October, 2003 00:04 > To: hardie@qualcomm.com > Cc: Simple WG > Subject: Re: [Simple] What can you do with a list? >=20 >=20 > Ted, >=20 > What you are talking about would correspond to saying yes to option > (1) below, and no to option (2). Scope creep and immaturity were some=20 > of the reasons for my mixed feelings on (2). Does anyone strongly=20 > believe it should be added? >=20 > Thanks, > Jonathan R. >=20 > hardie@qualcomm.com wrote: >=20 > > Hi Jonathan, I would suggest that if you decide to expand the scope > > of the work to include other permissible actions, that those > > actions be taken forward in separate drafts. That might require > > some re-writing of this draft (to make clear that the other drafts > > and actions may exist later), but it would allow the more mature=20 > > work to proceed without blocking on the semantics of the other=20 > > actions. Purely a personal commentary, regards, Ted Hardie > >=20 > >=20 > >=20 > > At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: > >=20 > >> Folks, > >>=20 > >> I'll be submitting a rev shortly to the xcap list draft:=20 > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-lis > t-usage-00.txt > >>=20 > >>=20 > >> There have been few comments on this document; its pretty > >> straightforward. > >>=20 > >> One issue was raised to me privately by Markus, which I think > >> merits broader discussion, is whether the scope of this draft is > >> just presence lists, or whether it is broader than that. In a > >> broader model, each URI representing a list has a set of > >> permissible actions that can be taken against the list. We have > >> "subscribable", which means you can subscribe to the list, but we > >> could allow other things. For example, we could add > >> "messageable", which means a MESSAGE request to that group we be > >> exploded (using Gonzalo's terminology) to those members. > >> "Invitable" would mean that an INVITE to that group would cause > >> creation of a conference call to that group. Clearly this > >> intersects with the conferencing work. > >>=20 > >> So, there are two questions: > >>=20 > >> (1) Do we want the draft to be broader than presence lists, and > >> mention that these are lists to which different operations can be > >> applied, > >>=20 > >> (2) Assuming (1), do we want to add explicit support for a > >> "messageable" boolean? > >>=20 > >> I think we should definitely do (1), I have mixed feelings on > >> (2), but am inclined to add it. > >>=20 > >> Comments? > >>=20 > >> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. > >> 600 Lanidex Plaza Chief Technology Officer > >> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>=20 > >>=20 > >>=20 > >> _______________________________________________ Simple mailing > >> list Simple@ietf.org=20 > >> https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 12:58:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03705 for ; Mon, 20 Oct 2003 12:58:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdMI-0004XK-QB for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 12:58:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KGwIOh017432 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 12:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdMI-0004X5-MQ for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 12:58:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03684; Mon, 20 Oct 2003 12:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdMG-0002H0-00; Mon, 20 Oct 2003 12:58:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdM6-0002Gp-00; Mon, 20 Oct 2003 12:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdM0-0004TH-VH; Mon, 20 Oct 2003 12:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdL3-0004KI-8G for simple@optimus.ietf.org; Mon, 20 Oct 2003 12:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03624 for ; Mon, 20 Oct 2003 12:56:50 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdL1-0002GR-00 for simple@ietf.org; Mon, 20 Oct 2003 12:56:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABdL0-0002GO-00 for simple@ietf.org; Mon, 20 Oct 2003 12:56:58 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KGuvd10080 for ; Mon, 20 Oct 2003 19:56:57 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 19:56:57 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 19:56:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] What can you do with a list? Message-ID: Thread-Topic: [Simple] What can you do with a list? Thread-Index: AcOWhLcPiE63xllyQSyE+BSDt5nxnwApDJJQ To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 16:56:57.0362 (UTC) FILETIME=[2BF8CF20:01C3972B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 19:56:56 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I'm also happy to go for option (1) now, and leave (2) for an extension. Having said that, I think we should do the support for MESSAGE request = to the list urgently too, since there are many products around doing = such things already, and it would be nice to get some interoperability = too. XCAP part is rather obvious, but I belive some discussion is needed = about the requirements on the SIP side. At least this comes to mind: - Do we want to support the reporting on success/failure of the = "exploder" to deliver the request to each destination on the list?=20 About and conferencing: From the user's point of view I = think it is clear that the same list should be usable for initiating = conferences too. But this could be done by issuing a CPCP command (based = on eventual XCON WG output) that is able to reference the HTTP URI of = the list too. I think the assumption in XCON is that CPCP would have = this kind of functionality (i.e. mass-invitation). Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 20 October, 2003 00:04 > To: hardie@qualcomm.com > Cc: Simple WG > Subject: Re: [Simple] What can you do with a list? >=20 >=20 > Ted, >=20 > What you are talking about would correspond to saying yes to option > (1) below, and no to option (2). Scope creep and immaturity were some=20 > of the reasons for my mixed feelings on (2). Does anyone strongly=20 > believe it should be added? >=20 > Thanks, > Jonathan R. >=20 > hardie@qualcomm.com wrote: >=20 > > Hi Jonathan, I would suggest that if you decide to expand the scope > > of the work to include other permissible actions, that those > > actions be taken forward in separate drafts. That might require > > some re-writing of this draft (to make clear that the other drafts > > and actions may exist later), but it would allow the more mature=20 > > work to proceed without blocking on the semantics of the other=20 > > actions. Purely a personal commentary, regards, Ted Hardie > >=20 > >=20 > >=20 > > At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: > >=20 > >> Folks, > >>=20 > >> I'll be submitting a rev shortly to the xcap list draft:=20 > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-lis > t-usage-00.txt > >>=20 > >>=20 > >> There have been few comments on this document; its pretty > >> straightforward. > >>=20 > >> One issue was raised to me privately by Markus, which I think > >> merits broader discussion, is whether the scope of this draft is > >> just presence lists, or whether it is broader than that. In a > >> broader model, each URI representing a list has a set of > >> permissible actions that can be taken against the list. We have > >> "subscribable", which means you can subscribe to the list, but we > >> could allow other things. For example, we could add > >> "messageable", which means a MESSAGE request to that group we be > >> exploded (using Gonzalo's terminology) to those members. > >> "Invitable" would mean that an INVITE to that group would cause > >> creation of a conference call to that group. Clearly this > >> intersects with the conferencing work. > >>=20 > >> So, there are two questions: > >>=20 > >> (1) Do we want the draft to be broader than presence lists, and > >> mention that these are lists to which different operations can be > >> applied, > >>=20 > >> (2) Assuming (1), do we want to add explicit support for a > >> "messageable" boolean? > >>=20 > >> I think we should definitely do (1), I have mixed feelings on > >> (2), but am inclined to add it. > >>=20 > >> Comments? > >>=20 > >> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. > >> 600 Lanidex Plaza Chief Technology Officer > >> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >> FAX: (973) 952-5050 http://www.jdrosen.net > >> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>=20 > >>=20 > >>=20 > >> _______________________________________________ Simple mailing > >> list Simple@ietf.org=20 > >> https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 13:29:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04796; Mon, 20 Oct 2003 13:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdr5-0002bX-00; Mon, 20 Oct 2003 13:30:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdr4-0002bT-00; Mon, 20 Oct 2003 13:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqy-0002TY-V0; Mon, 20 Oct 2003 13:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqn-0002Rd-GQ for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:29:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04746 for ; Mon, 20 Oct 2003 13:29:38 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdql-0002au-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:47 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqk-0002ar-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:46 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHTgd13032 for ; Mon, 20 Oct 2003 20:29:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:29:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 20:29:40 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] What can you do with a list? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701947C51@esebe019.ntc.nokia.com> Thread-Topic: [Simple] What can you do with a list? Thread-Index: AcOWhLF4X7uw/A4NSBmhu3UFtc3lqgAWga1gAA9LYNA= To: , , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:29:40.0939 (UTC) FILETIME=[BE5AE1B0:01C3972F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:29:40 +0300 Content-Transfer-Encoding: quoted-printable I think (2) is needed. If you would like to pursue option 1 for now, but = delay 2, then I suggest removing any text referring to the list as a = presence list. There is nothing in the draft that tells what package is the list = "subscrible" for. It is assumed that it is the presence event package. = If you want to extract those service specifics, again, I suggest not = referring to presence in this draft. We could then would write a draft for "subscribe to presence", = "messagable", etc. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: Monday, October 20, 2003 10:53 AM > To: Jonathan Rosenberg; hardie@qualcomm.com > Cc: Simple WG > Subject: RE: [Simple] What can you do with a list? >=20 >=20 > Jonathan, > I agree with Ted on this one - I certainly think it would be > beneficial to open up lists for other operations BUT these should be > extensions from the base draft. So (1) and not (2). >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: 19 October 2003 22:04 > >To: hardie@qualcomm.com > >Cc: Simple WG > >Subject: Re: [Simple] What can you do with a list? > > > >Ted, > > > >What you are talking about would correspond to saying yes to option > >(1) below, and no to option (2). Scope creep and immaturity were some > >of the reasons for my mixed feelings on (2). Does anyone strongly > >believe it should be added? > > > >Thanks, > >Jonathan R. > > > >hardie@qualcomm.com wrote: > > > >> Hi Jonathan, I would suggest that if you decide to expand the scope > >> of the work to include other permissible actions, that those > >> actions be taken forward in separate drafts. That might require > >> some re-writing of this draft (to make clear that the other drafts > >> and actions may exist later), but it would allow the more mature > >> work to proceed without blocking on the semantics of the other > >> actions. Purely a personal commentary, regards, Ted Hardie > >> > >> > >> > >> At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: > >> > >>> Folks, > >>> > >>> I'll be submitting a rev shortly to the xcap list draft: > >>> > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage- > >00.txt > >>> > >>> > >>> There have been few comments on this document; its pretty > >>> straightforward. > >>> > >>> One issue was raised to me privately by Markus, which I think > >>> merits broader discussion, is whether the scope of this draft is > >>> just presence lists, or whether it is broader than that. In a > >>> broader model, each URI representing a list has a set of > >>> permissible actions that can be taken against the list. We have > >>> "subscribable", which means you can subscribe to the list, but we > >>> could allow other things. For example, we could add > >>> "messageable", which means a MESSAGE request to that group we be > >>> exploded (using Gonzalo's terminology) to those members. > >>> "Invitable" would mean that an INVITE to that group would cause > >>> creation of a conference call to that group. Clearly this > >>> intersects with the conferencing work. > >>> > >>> So, there are two questions: > >>> > >>> (1) Do we want the draft to be broader than presence lists, and > >>> mention that these are lists to which different operations can be > >>> applied, > >>> > >>> (2) Assuming (1), do we want to add explicit support for a > >>> "messageable" boolean? > >>> > >>> I think we should definitely do (1), I have mixed feelings on > >>> (2), but am inclined to add it. > >>> > >>> Comments? > >>> > >>> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. > >>> 600 Lanidex Plaza Chief Technology Officer > >>> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >>> FAX: (973) 952-5050 http://www.jdrosen.net > >>> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>> > >>> > >>> > >>> _______________________________________________ Simple mailing > >>> list Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > > > >-- > >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >Chief Technology Officer Parsippany, NJ 07054-2711 > >dynamicsoft > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.jdrosen.net PHONE: (973) 952-5000 > >http://www.dynamicsoft.com > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:30:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04846 for ; Mon, 20 Oct 2003 13:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdr7-0002YC-Um for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHU9Jk009798 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdr7-0002Xx-Oy for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:30:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04794; Mon, 20 Oct 2003 13:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdr5-0002ba-00; Mon, 20 Oct 2003 13:30:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdr4-0002bU-00; Mon, 20 Oct 2003 13:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdr0-0002Tv-CF; Mon, 20 Oct 2003 13:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqp-0002Ry-36 for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04749 for ; Mon, 20 Oct 2003 13:29:40 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqn-0002az-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqm-0002aq-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:48 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHTfd13001 for ; Mon, 20 Oct 2003 20:29:41 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:29:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 20:29:40 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOU1o4IMBXRwzxIThOAGbVc14rbfACQ71Pg To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:29:40.0476 (UTC) FILETIME=[BE143BC0:01C3972F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:29:40 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, October 17, 2003 8:44 PM > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 > Based on recent discussions, I think we may need to rethink this. The=20 > point to resending was _not_ to build a reliability mechanism=20 > on top of=20 > TCP. We really wanted a mechanism to simply warn the user if we could=20 > not be sure the opposite endpoint had actually processed the=20 > message. I=20 > think we should either remove the text encouraging re-submission, or=20 > change it to re-use the same TR-ID, and add text to describe what the=20 > peer should do if it sees duplicate TR-IDs. I would hate to resend a 5gb message. I think there should be a timer = for the response, without retransmissions. If the timer fires, then you = have to assume that something went wrong in delivering the message. = Retransmission won't help. >=20 > Having a response delayed by a long request in the recipricol=20 > direction=20 > is a problem I don't think we have considered. I welcome input as to=20 > whether we think this is a real issue, and if so, how to deal with it. I thought we agreed that large messages should be sent using a separate = session. Or we change that decision? If not, I cannot recall if there = was a threshold that classifies as message as large. /Hisham >=20 > Aki Niemi wrote: >=20 > > Hi, > >=20 > > In the draft, if a SEND times out, the MSRP client is=20 > supposed to handle=20 > > this as if a 5xx was received. I.e., it will resend the=20 > message a few=20 > > times and then quit the session. In case the other endpoint=20 > is in the=20 > > midst of sending a large message, a response may take =20 > longer than the=20 > > request time out value. This will result in a number of duplicate=20 > > messages received. There should be a better way to handle this. Why=20 > > resend in the first place, especially if the connection is active? > >=20 > > Also, what is the motivation for making retransmissions=20 > with a different=20 > > TR-ID? Doesn't this go agains the idea of retrying the request? > >=20 > > Regards, > > Aki > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:30:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04861 for ; Mon, 20 Oct 2003 13:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdr8-0002YO-0l for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:30:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHU9ok009809 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdr7-0002Y4-TA for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:30:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04796; Mon, 20 Oct 2003 13:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdr5-0002bX-00; Mon, 20 Oct 2003 13:30:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdr4-0002bT-00; Mon, 20 Oct 2003 13:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqy-0002TY-V0; Mon, 20 Oct 2003 13:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqn-0002Rd-GQ for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:29:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04746 for ; Mon, 20 Oct 2003 13:29:38 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdql-0002au-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:47 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqk-0002ar-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:46 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHTgd13032 for ; Mon, 20 Oct 2003 20:29:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:29:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 20:29:40 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] What can you do with a list? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701947C51@esebe019.ntc.nokia.com> Thread-Topic: [Simple] What can you do with a list? Thread-Index: AcOWhLF4X7uw/A4NSBmhu3UFtc3lqgAWga1gAA9LYNA= To: , , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:29:40.0939 (UTC) FILETIME=[BE5AE1B0:01C3972F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:29:40 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think (2) is needed. If you would like to pursue option 1 for now, but = delay 2, then I suggest removing any text referring to the list as a = presence list. There is nothing in the draft that tells what package is the list = "subscrible" for. It is assumed that it is the presence event package. = If you want to extract those service specifics, again, I suggest not = referring to presence in this draft. We could then would write a draft for "subscribe to presence", = "messagable", etc. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: Monday, October 20, 2003 10:53 AM > To: Jonathan Rosenberg; hardie@qualcomm.com > Cc: Simple WG > Subject: RE: [Simple] What can you do with a list? >=20 >=20 > Jonathan, > I agree with Ted on this one - I certainly think it would be > beneficial to open up lists for other operations BUT these should be > extensions from the base draft. So (1) and not (2). >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: 19 October 2003 22:04 > >To: hardie@qualcomm.com > >Cc: Simple WG > >Subject: Re: [Simple] What can you do with a list? > > > >Ted, > > > >What you are talking about would correspond to saying yes to option > >(1) below, and no to option (2). Scope creep and immaturity were some > >of the reasons for my mixed feelings on (2). Does anyone strongly > >believe it should be added? > > > >Thanks, > >Jonathan R. > > > >hardie@qualcomm.com wrote: > > > >> Hi Jonathan, I would suggest that if you decide to expand the scope > >> of the work to include other permissible actions, that those > >> actions be taken forward in separate drafts. That might require > >> some re-writing of this draft (to make clear that the other drafts > >> and actions may exist later), but it would allow the more mature > >> work to proceed without blocking on the semantics of the other > >> actions. Purely a personal commentary, regards, Ted Hardie > >> > >> > >> > >> At 3:03 PM -0400 10/17/2003, Jonathan Rosenberg wrote: > >> > >>> Folks, > >>> > >>> I'll be submitting a rev shortly to the xcap list draft: > >>> > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage- > >00.txt > >>> > >>> > >>> There have been few comments on this document; its pretty > >>> straightforward. > >>> > >>> One issue was raised to me privately by Markus, which I think > >>> merits broader discussion, is whether the scope of this draft is > >>> just presence lists, or whether it is broader than that. In a > >>> broader model, each URI representing a list has a set of > >>> permissible actions that can be taken against the list. We have > >>> "subscribable", which means you can subscribe to the list, but we > >>> could allow other things. For example, we could add > >>> "messageable", which means a MESSAGE request to that group we be > >>> exploded (using Gonzalo's terminology) to those members. > >>> "Invitable" would mean that an INVITE to that group would cause > >>> creation of a conference call to that group. Clearly this > >>> intersects with the conferencing work. > >>> > >>> So, there are two questions: > >>> > >>> (1) Do we want the draft to be broader than presence lists, and > >>> mention that these are lists to which different operations can be > >>> applied, > >>> > >>> (2) Assuming (1), do we want to add explicit support for a > >>> "messageable" boolean? > >>> > >>> I think we should definitely do (1), I have mixed feelings on > >>> (2), but am inclined to add it. > >>> > >>> Comments? > >>> > >>> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. > >>> 600 Lanidex Plaza Chief Technology Officer > >>> Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com > >>> FAX: (973) 952-5050 http://www.jdrosen.net > >>> PHONE: (973) 952-5000 http://www.dynamicsoft.com > >>> > >>> > >>> > >>> _______________________________________________ Simple mailing > >>> list Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > > > >-- > >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >Chief Technology Officer Parsippany, NJ 07054-2711 > >dynamicsoft > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.jdrosen.net PHONE: (973) 952-5000 > >http://www.dynamicsoft.com > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 13:36:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05035; Mon, 20 Oct 2003 13:36:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdwx-0002fZ-00; Mon, 20 Oct 2003 13:36:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdwx-0002fW-00; Mon, 20 Oct 2003 13:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdwn-0003gs-PA; Mon, 20 Oct 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdwU-0003bl-CH for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:35:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05004 for ; Mon, 20 Oct 2003 13:35:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdwS-0002et-00 for simple@ietf.org; Mon, 20 Oct 2003 13:35:40 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABdwR-0002eq-00 for simple@ietf.org; Mon, 20 Oct 2003 13:35:39 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KHZMF8009183; Mon, 20 Oct 2003 12:35:26 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F941CC8.1090903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A3@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A3@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 12:35:04 -0500 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: [...] > > Sure, it says the connection should be torn down. It does not say > > anything at all about whether a client should automatically > > attempt to > > create a new session or not. I don't think we should specify > > that sort > > of behavior one way or another. It does not seem to affect > > interoperability in any way. > > OK, then I misinterpreted you before. I thought by auto-resume, the MSRP client would try to resume the *MSRP* session, meaning something like establish a new TCP connection, do a VISIT, etc. Maybe some clarification to the term "session" is needed here? > > One thing related to this though, in case an MSRP peer wants to establish a new MSRP connection for e.g. filetransfer, should it assume the "direction" properties of the existing MSRP session, or should the endpoints do a full handshake on it? > > My proposal (which would require some text in MSRP) would be that the directional proerties of the original MSRP connection are reused. I would expect the circumstances in the network to remain constant, so that the direction of the new MSRP session would likely turn out the same as the original one. > Why do we need to special case this? I don't think the added efficiency is enough to justify the special case. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:36:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05073 for ; Mon, 20 Oct 2003 13:36:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdx0-0003ns-M5 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:36:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHaEAH014614 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:36:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdx0-0003nd-Is for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:36:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05035; Mon, 20 Oct 2003 13:36:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdwx-0002fZ-00; Mon, 20 Oct 2003 13:36:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdwx-0002fW-00; Mon, 20 Oct 2003 13:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdwn-0003gs-PA; Mon, 20 Oct 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdwU-0003bl-CH for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:35:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05004 for ; Mon, 20 Oct 2003 13:35:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdwS-0002et-00 for simple@ietf.org; Mon, 20 Oct 2003 13:35:40 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABdwR-0002eq-00 for simple@ietf.org; Mon, 20 Oct 2003 13:35:39 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KHZMF8009183; Mon, 20 Oct 2003 12:35:26 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F941CC8.1090903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A3@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D90A3@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 12:35:04 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: [...] > > Sure, it says the connection should be torn down. It does not say > > anything at all about whether a client should automatically > > attempt to > > create a new session or not. I don't think we should specify > > that sort > > of behavior one way or another. It does not seem to affect > > interoperability in any way. > > OK, then I misinterpreted you before. I thought by auto-resume, the MSRP client would try to resume the *MSRP* session, meaning something like establish a new TCP connection, do a VISIT, etc. Maybe some clarification to the term "session" is needed here? > > One thing related to this though, in case an MSRP peer wants to establish a new MSRP connection for e.g. filetransfer, should it assume the "direction" properties of the existing MSRP session, or should the endpoints do a full handshake on it? > > My proposal (which would require some text in MSRP) would be that the directional proerties of the original MSRP connection are reused. I would expect the circumstances in the network to remain constant, so that the direction of the new MSRP session would likely turn out the same as the original one. > Why do we need to special case this? I don't think the added efficiency is enough to justify the special case. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 13:38:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05185; Mon, 20 Oct 2003 13:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdzg-0002h6-00; Mon, 20 Oct 2003 13:39:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdzg-0002h3-00; Mon, 20 Oct 2003 13:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdzg-0004ld-Ro; Mon, 20 Oct 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdyn-0004Z9-6A for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05178 for ; Mon, 20 Oct 2003 13:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdyl-0002gw-00 for simple@ietf.org; Mon, 20 Oct 2003 13:38:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABdyk-0002gt-00 for simple@ietf.org; Mon, 20 Oct 2003 13:38:02 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KHbsF8009358; Mon, 20 Oct 2003 12:38:01 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F941D61.2090800@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 12:37:37 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, October 17, 2003 8:44 PM >>To: Niemi Aki (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP comments - request/response handling and >>retrying >> >> >>Based on recent discussions, I think we may need to rethink this. The >>point to resending was _not_ to build a reliability mechanism >>on top of >>TCP. We really wanted a mechanism to simply warn the user if we could >>not be sure the opposite endpoint had actually processed the >>message. I >>think we should either remove the text encouraging re-submission, or >>change it to re-use the same TR-ID, and add text to describe what the >>peer should do if it sees duplicate TR-IDs. > > > > I would hate to resend a 5gb message. I think there should be a timer for the response, without retransmissions. If the timer fires, then you have to assume that something went wrong in delivering the message. Retransmission won't help. > > >>Having a response delayed by a long request in the recipricol >>direction >>is a problem I don't think we have considered. I welcome input as to >>whether we think this is a real issue, and if so, how to deal with it. > > > I thought we agreed that large messages should be sent using a separate session. Or we change that decision? If not, I cannot recall if there was a threshold that classifies as message as large. You are correct, we have text encouraging this behavior. Since you reminded me of this, and no one else jumped in to say that this is a big problem, I am going to assume for now that it is not. If anyone feels otherwise, please jump in asap. > > /Hisham > > >>Aki Niemi wrote: >> >> >>>Hi, >>> >>>In the draft, if a SEND times out, the MSRP client is >> >>supposed to handle >> >>>this as if a 5xx was received. I.e., it will resend the >> >>message a few >> >>>times and then quit the session. In case the other endpoint >> >>is in the >> >>>midst of sending a large message, a response may take >> >>longer than the >> >>>request time out value. This will result in a number of duplicate >>>messages received. There should be a better way to handle this. Why >>>resend in the first place, especially if the connection is active? >>> >>>Also, what is the motivation for making retransmissions >> >>with a different >> >>>TR-ID? Doesn't this go agains the idea of retrying the request? >>> >>>Regards, >>>Aki >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:39:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05209 for ; Mon, 20 Oct 2003 13:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdzj-0004nc-E2 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHd3h7018442 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdzj-0004nN-AJ for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05185; Mon, 20 Oct 2003 13:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdzg-0002h6-00; Mon, 20 Oct 2003 13:39:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdzg-0002h3-00; Mon, 20 Oct 2003 13:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdzg-0004ld-Ro; Mon, 20 Oct 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdyn-0004Z9-6A for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05178 for ; Mon, 20 Oct 2003 13:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdyl-0002gw-00 for simple@ietf.org; Mon, 20 Oct 2003 13:38:03 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABdyk-0002gt-00 for simple@ietf.org; Mon, 20 Oct 2003 13:38:02 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KHbsF8009358; Mon, 20 Oct 2003 12:38:01 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F941D61.2090800@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 12:37:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, October 17, 2003 8:44 PM >>To: Niemi Aki (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP comments - request/response handling and >>retrying >> >> >>Based on recent discussions, I think we may need to rethink this. The >>point to resending was _not_ to build a reliability mechanism >>on top of >>TCP. We really wanted a mechanism to simply warn the user if we could >>not be sure the opposite endpoint had actually processed the >>message. I >>think we should either remove the text encouraging re-submission, or >>change it to re-use the same TR-ID, and add text to describe what the >>peer should do if it sees duplicate TR-IDs. > > > > I would hate to resend a 5gb message. I think there should be a timer for the response, without retransmissions. If the timer fires, then you have to assume that something went wrong in delivering the message. Retransmission won't help. > > >>Having a response delayed by a long request in the recipricol >>direction >>is a problem I don't think we have considered. I welcome input as to >>whether we think this is a real issue, and if so, how to deal with it. > > > I thought we agreed that large messages should be sent using a separate session. Or we change that decision? If not, I cannot recall if there was a threshold that classifies as message as large. You are correct, we have text encouraging this behavior. Since you reminded me of this, and no one else jumped in to say that this is a big problem, I am going to assume for now that it is not. If anyone feels otherwise, please jump in asap. > > /Hisham > > >>Aki Niemi wrote: >> >> >>>Hi, >>> >>>In the draft, if a SEND times out, the MSRP client is >> >>supposed to handle >> >>>this as if a 5xx was received. I.e., it will resend the >> >>message a few >> >>>times and then quit the session. In case the other endpoint >> >>is in the >> >>>midst of sending a large message, a response may take >> >>longer than the >> >>>request time out value. This will result in a number of duplicate >>>messages received. There should be a better way to handle this. Why >>>resend in the first place, especially if the connection is active? >>> >>>Also, what is the motivation for making retransmissions >> >>with a different >> >>>TR-ID? Doesn't this go agains the idea of retrying the request? >>> >>>Regards, >>>Aki >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 13:48:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05440; Mon, 20 Oct 2003 13:48:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABe9O-0002n5-00; Mon, 20 Oct 2003 13:49:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABe9O-0002n2-00; Mon, 20 Oct 2003 13:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABe9M-0007cr-Sg; Mon, 20 Oct 2003 13:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABe8f-0007NE-Qg for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05414 for ; Mon, 20 Oct 2003 13:48:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABe8d-0002mS-00 for simple@ietf.org; Mon, 20 Oct 2003 13:48:15 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABe8c-0002mP-00 for simple@ietf.org; Mon, 20 Oct 2003 13:48:15 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHmEX00431 for ; Mon, 20 Oct 2003 20:48:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:48:14 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 20:48:14 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Comments - Keepalive X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQACiBwlA= To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:48:14.0208 (UTC) FILETIME=[55EA4000:01C39732] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:48:13 +0300 Content-Transfer-Encoding: quoted-printable I'm in favour of not overloading method semantics and therefore agree = with Aki. KEEPALIVE sounds ok. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext aki.niemi@nokia.com > Sent: Monday, October 20, 2003 1:03 PM > To: bcampbell@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] MSRP Comments - Keepalive >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 17 October, 2003 20:49 > > To: Niemi Aki (NMP/Helsinki) > > Cc: simple@ietf.org > > Subject: Re: [Simple] MSRP Comments - Keepalive > >=20 > >=20 > > The reasoning was, from a relay's perspective, it watchers for IM=20 > > traffic to determine liveness. Clients that don't have any _other_=20 > > traffic to send should just generate some frome time to=20 > > time. There is=20 > > nothing particularly special about the traffic generated.=20 > Sending an=20 > > empty message seemed to have exactly these semantics. >=20 > I don't think there is anything wrong with this reasoning. >=20 > > From an endpoints perspective, I could see adding a new=20 > > method if we=20 > > wanted some special semantic handling that is different than=20 > > for SEND.=20 > > But I don't see how the receiver semantics for a=20 > "KEEPALIVE" method=20 > > would be any different than for an empty SEND method. >=20 > That is certainly true. I don't think there is a difference=20 > in semantics. >=20 > Where I think something like KEEPALIVE would help is in=20 > specification clarity. I think it's better to keep things=20 > explicit. If in total, this would save a few posts on=20 > sip-implementors that doubt the "special" nature of a SEND=20 > without a body, then I think it's worth doing. >=20 > On the other hand, as a drawback to the KEEPALIVE method, it=20 > would require defining a new method with it's associated=20 > specification work, which I don't believe is a considerable=20 > burden though. Is there any other reason to prefer an empty=20 > SEND over a KEEPALIVE? >=20 > Regards, > Aki > =20 > >=20 > > Aki Niemi wrote: > >=20 > > > Hi, > > >=20 > > > I know this is the sort of thing people usually use as=20 > > flamebait, but I=20 > > > just have to ask ;-) > > >=20 > > > Why overload the SEND for keepalive? Is there a specific=20 > reason to=20 > > > minimize the number of methods in this protocol? I don't see the=20 > > > complexity added by having a function that clearly does=20 > something=20 > > > specific have its own method name, too. > > >=20 > > > Regards, > > > Aki > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:49:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05467 for ; Mon, 20 Oct 2003 13:49:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABe9R-0007fs-Fw for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHn561029501 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABe9R-0007fR-7P for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:49:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05440; Mon, 20 Oct 2003 13:48:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABe9O-0002n5-00; Mon, 20 Oct 2003 13:49:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABe9O-0002n2-00; Mon, 20 Oct 2003 13:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABe9M-0007cr-Sg; Mon, 20 Oct 2003 13:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABe8f-0007NE-Qg for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05414 for ; Mon, 20 Oct 2003 13:48:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABe8d-0002mS-00 for simple@ietf.org; Mon, 20 Oct 2003 13:48:15 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABe8c-0002mP-00 for simple@ietf.org; Mon, 20 Oct 2003 13:48:15 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHmEX00431 for ; Mon, 20 Oct 2003 20:48:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:48:14 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 20:48:14 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Comments - Keepalive X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQACiBwlA= To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:48:14.0208 (UTC) FILETIME=[55EA4000:01C39732] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:48:13 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm in favour of not overloading method semantics and therefore agree = with Aki. KEEPALIVE sounds ok. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext aki.niemi@nokia.com > Sent: Monday, October 20, 2003 1:03 PM > To: bcampbell@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] MSRP Comments - Keepalive >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 17 October, 2003 20:49 > > To: Niemi Aki (NMP/Helsinki) > > Cc: simple@ietf.org > > Subject: Re: [Simple] MSRP Comments - Keepalive > >=20 > >=20 > > The reasoning was, from a relay's perspective, it watchers for IM=20 > > traffic to determine liveness. Clients that don't have any _other_=20 > > traffic to send should just generate some frome time to=20 > > time. There is=20 > > nothing particularly special about the traffic generated.=20 > Sending an=20 > > empty message seemed to have exactly these semantics. >=20 > I don't think there is anything wrong with this reasoning. >=20 > > From an endpoints perspective, I could see adding a new=20 > > method if we=20 > > wanted some special semantic handling that is different than=20 > > for SEND.=20 > > But I don't see how the receiver semantics for a=20 > "KEEPALIVE" method=20 > > would be any different than for an empty SEND method. >=20 > That is certainly true. I don't think there is a difference=20 > in semantics. >=20 > Where I think something like KEEPALIVE would help is in=20 > specification clarity. I think it's better to keep things=20 > explicit. If in total, this would save a few posts on=20 > sip-implementors that doubt the "special" nature of a SEND=20 > without a body, then I think it's worth doing. >=20 > On the other hand, as a drawback to the KEEPALIVE method, it=20 > would require defining a new method with it's associated=20 > specification work, which I don't believe is a considerable=20 > burden though. Is there any other reason to prefer an empty=20 > SEND over a KEEPALIVE? >=20 > Regards, > Aki > =20 > >=20 > > Aki Niemi wrote: > >=20 > > > Hi, > > >=20 > > > I know this is the sort of thing people usually use as=20 > > flamebait, but I=20 > > > just have to ask ;-) > > >=20 > > > Why overload the SEND for keepalive? Is there a specific=20 > reason to=20 > > > minimize the number of methods in this protocol? I don't see the=20 > > > complexity added by having a function that clearly does=20 > something=20 > > > specific have its own method name, too. > > >=20 > > > Regards, > > > Aki > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 13:51:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05506; Mon, 20 Oct 2003 13:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeBP-0002o3-00; Mon, 20 Oct 2003 13:51:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeBP-0002o0-00; Mon, 20 Oct 2003 13:51:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeBK-0008H2-Rd; Mon, 20 Oct 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeAp-00089K-Ep for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:50:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05496 for ; Mon, 20 Oct 2003 13:50:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeAn-0002nl-00 for simple@ietf.org; Mon, 20 Oct 2003 13:50:29 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABeAm-0002ni-00 for simple@ietf.org; Mon, 20 Oct 2003 13:50:28 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHoRX02540 for ; Mon, 20 Oct 2003 20:50:27 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:50:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 20:50:25 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Comments - Keepalive X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQABiapjAAEAJREA== To: , , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:50:25.0735 (UTC) FILETIME=[A44FAD70:01C39732] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:50:25 +0300 Content-Transfer-Encoding: quoted-printable Why don't we have just the one method and define semantics using mime = type bodies. This is exactly the same arguments we have in SIP. Why = wouldn't they apply here? /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: Monday, October 20, 2003 1:15 PM > To: Niemi Aki (NMP/Helsinki); bcampbell@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] MSRP Comments - Keepalive >=20 >=20 > <> >=20 > >-----Original Message----- > >From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > >Sent: 20 October 2003 11:03 > >To: bcampbell@dynamicsoft.com > >Cc: simple@ietf.org > >Subject: RE: [Simple] MSRP Comments - Keepalive > > > > > > > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: 17 October, 2003 20:49 > > > To: Niemi Aki (NMP/Helsinki) > > > Cc: simple@ietf.org > > > Subject: Re: [Simple] MSRP Comments - Keepalive > > > > > > > > > The reasoning was, from a relay's perspective, it watchers for IM > > > traffic to determine liveness. Clients that don't have any _other_ > > > traffic to send should just generate some frome time to > > > time. There is > > > nothing particularly special about the traffic generated.=20 > Sending an > > > empty message seemed to have exactly these semantics. > > > >I don't think there is anything wrong with this reasoning. > > > > > From an endpoints perspective, I could see adding a new > > > method if we > > > wanted some special semantic handling that is different than > > > for SEND. > > > But I don't see how the receiver semantics for a=20 > "KEEPALIVE" method > > > would be any different than for an empty SEND method. > > > >That is certainly true. I don't think there is a difference in > semantics. > > > >Where I think something like KEEPALIVE would help is in specification > >clarity. I think it's better to keep things explicit. If in=20 > total, this > >would save a few posts on sip-implementors that doubt the "special" > nature > >of a SEND without a body, then I think it's worth doing. > > > >On the other hand, as a drawback to the KEEPALIVE method, it would > require > >defining a new method with it's associated specification=20 > work, which I > >don't believe is a considerable burden though. Is there any other > reason to > >prefer an empty SEND over a KEEPALIVE? >=20 > [Chris Boulton] The only real reason I can think of is to maintain the > 'lets keep it simple and light weight' philosophy that MSRP champions. > I don't have a problem with creating a new method for this=20 > functionality > BUT I think we need to be careful when crating new methods for > functionality where appropriate semantics already exist. As=20 > long as the > refresh operation is explicitly defined, I just don't see the need. >=20 > Chris. >=20 >=20 > > > >Regards, > >Aki > > > > > > > > Aki Niemi wrote: > > > > > > > Hi, > > > > > > > > I know this is the sort of thing people usually use as > > > flamebait, but I > > > > just have to ask ;-) > > > > > > > > Why overload the SEND for keepalive? Is there a=20 > specific reason to > > > > minimize the number of methods in this protocol? I don't see the > > > > complexity added by having a function that clearly does=20 > something > > > > specific have its own method name, too. > > > > > > > > Regards, > > > > Aki > > > > > > > > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05530 for ; Mon, 20 Oct 2003 13:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeBS-0008MS-97 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHpAX1032141 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeBS-0008MK-5N for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05506; Mon, 20 Oct 2003 13:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeBP-0002o3-00; Mon, 20 Oct 2003 13:51:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeBP-0002o0-00; Mon, 20 Oct 2003 13:51:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeBK-0008H2-Rd; Mon, 20 Oct 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeAp-00089K-Ep for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:50:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05496 for ; Mon, 20 Oct 2003 13:50:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeAn-0002nl-00 for simple@ietf.org; Mon, 20 Oct 2003 13:50:29 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABeAm-0002ni-00 for simple@ietf.org; Mon, 20 Oct 2003 13:50:28 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHoRX02540 for ; Mon, 20 Oct 2003 20:50:27 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:50:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 20:50:25 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Comments - Keepalive X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Comments - Keepalive Thread-Index: AcOU1u6nAk7RsfkjQ0+VKzXBlMlCkQBuQ3mQABiapjAAEAJREA== To: , , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:50:25.0735 (UTC) FILETIME=[A44FAD70:01C39732] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:50:25 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Why don't we have just the one method and define semantics using mime = type bodies. This is exactly the same arguments we have in SIP. Why = wouldn't they apply here? /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: Monday, October 20, 2003 1:15 PM > To: Niemi Aki (NMP/Helsinki); bcampbell@dynamicsoft.com > Cc: simple@ietf.org > Subject: RE: [Simple] MSRP Comments - Keepalive >=20 >=20 > <> >=20 > >-----Original Message----- > >From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > >Sent: 20 October 2003 11:03 > >To: bcampbell@dynamicsoft.com > >Cc: simple@ietf.org > >Subject: RE: [Simple] MSRP Comments - Keepalive > > > > > > > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: 17 October, 2003 20:49 > > > To: Niemi Aki (NMP/Helsinki) > > > Cc: simple@ietf.org > > > Subject: Re: [Simple] MSRP Comments - Keepalive > > > > > > > > > The reasoning was, from a relay's perspective, it watchers for IM > > > traffic to determine liveness. Clients that don't have any _other_ > > > traffic to send should just generate some frome time to > > > time. There is > > > nothing particularly special about the traffic generated.=20 > Sending an > > > empty message seemed to have exactly these semantics. > > > >I don't think there is anything wrong with this reasoning. > > > > > From an endpoints perspective, I could see adding a new > > > method if we > > > wanted some special semantic handling that is different than > > > for SEND. > > > But I don't see how the receiver semantics for a=20 > "KEEPALIVE" method > > > would be any different than for an empty SEND method. > > > >That is certainly true. I don't think there is a difference in > semantics. > > > >Where I think something like KEEPALIVE would help is in specification > >clarity. I think it's better to keep things explicit. If in=20 > total, this > >would save a few posts on sip-implementors that doubt the "special" > nature > >of a SEND without a body, then I think it's worth doing. > > > >On the other hand, as a drawback to the KEEPALIVE method, it would > require > >defining a new method with it's associated specification=20 > work, which I > >don't believe is a considerable burden though. Is there any other > reason to > >prefer an empty SEND over a KEEPALIVE? >=20 > [Chris Boulton] The only real reason I can think of is to maintain the > 'lets keep it simple and light weight' philosophy that MSRP champions. > I don't have a problem with creating a new method for this=20 > functionality > BUT I think we need to be careful when crating new methods for > functionality where appropriate semantics already exist. As=20 > long as the > refresh operation is explicitly defined, I just don't see the need. >=20 > Chris. >=20 >=20 > > > >Regards, > >Aki > > > > > > > > Aki Niemi wrote: > > > > > > > Hi, > > > > > > > > I know this is the sort of thing people usually use as > > > flamebait, but I > > > > just have to ask ;-) > > > > > > > > Why overload the SEND for keepalive? Is there a=20 > specific reason to > > > > minimize the number of methods in this protocol? I don't see the > > > > complexity added by having a function that clearly does=20 > something > > > > specific have its own method name, too. > > > > > > > > Regards, > > > > Aki > > > > > > > > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 13:53:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05585; Mon, 20 Oct 2003 13:53:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeEI-0002pK-00; Mon, 20 Oct 2003 13:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeEI-0002pF-00; Mon, 20 Oct 2003 13:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeED-0000Qj-9B; Mon, 20 Oct 2003 13:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeDU-0000HN-BU for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:53:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05558 for ; Mon, 20 Oct 2003 13:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeDS-0002oh-00 for simple@ietf.org; Mon, 20 Oct 2003 13:53:14 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABeDR-0002od-00 for simple@ietf.org; Mon, 20 Oct 2003 13:53:13 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KHr4F8010872; Mon, 20 Oct 2003 12:53:10 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F9420EE.8000200@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP Comments - Keepalive References: <2038BCC78B1AD641891A0D1AE133DBB7017972BC@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972BC@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 12:52:46 -0500 Content-Transfer-Encoding: 7bit I will re-iterate that I do not see this as overloading method semantics. The relays do not even know that keepalives exist--nor should they. All they are doing is watching how much time has passed since the last SEND request. I believe the empty SEND request was the consensus of the room in the interim meeting. Are there others that share the opinion that we need to change this to a new method? hisham.khartabil@nokia.com wrote: > I'm in favour of not overloading method semantics and therefore agree with Aki. > > KEEPALIVE sounds ok. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext aki.niemi@nokia.com >>Sent: Monday, October 20, 2003 1:03 PM >>To: bcampbell@dynamicsoft.com >>Cc: simple@ietf.org >>Subject: RE: [Simple] MSRP Comments - Keepalive >> >> >> >> >> > -----Original Message----- >> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> > Sent: 17 October, 2003 20:49 >> > To: Niemi Aki (NMP/Helsinki) >> > Cc: simple@ietf.org >> > Subject: Re: [Simple] MSRP Comments - Keepalive >> > >> > >> > The reasoning was, from a relay's perspective, it watchers for IM >> > traffic to determine liveness. Clients that don't have any _other_ >> > traffic to send should just generate some frome time to >> > time. There is >> > nothing particularly special about the traffic generated. >>Sending an >> > empty message seemed to have exactly these semantics. >> >>I don't think there is anything wrong with this reasoning. >> >> > From an endpoints perspective, I could see adding a new >> > method if we >> > wanted some special semantic handling that is different than >> > for SEND. >> > But I don't see how the receiver semantics for a >>"KEEPALIVE" method >> > would be any different than for an empty SEND method. >> >>That is certainly true. I don't think there is a difference >>in semantics. >> >>Where I think something like KEEPALIVE would help is in >>specification clarity. I think it's better to keep things >>explicit. If in total, this would save a few posts on >>sip-implementors that doubt the "special" nature of a SEND >>without a body, then I think it's worth doing. >> >>On the other hand, as a drawback to the KEEPALIVE method, it >>would require defining a new method with it's associated >>specification work, which I don't believe is a considerable >>burden though. Is there any other reason to prefer an empty >>SEND over a KEEPALIVE? >> >>Regards, >>Aki >> >> > >> > Aki Niemi wrote: >> > >> > > Hi, >> > > >> > > I know this is the sort of thing people usually use as >> > flamebait, but I >> > > just have to ask ;-) >> > > >> > > Why overload the SEND for keepalive? Is there a specific >>reason to >> > > minimize the number of methods in this protocol? I don't see the >> > > complexity added by having a function that clearly does >>something >> > > specific have its own method name, too. >> > > >> > > Regards, >> > > Aki >> > > >> > > >> > > >> > > _______________________________________________ >> > > Simple mailing list >> > > Simple@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/simple >> > >> > >> > >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 13:54:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05637 for ; Mon, 20 Oct 2003 13:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeEL-0000Xd-Fx for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:54:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHs9AX002075 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 13:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeEL-0000XO-CF for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05585; Mon, 20 Oct 2003 13:53:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeEI-0002pK-00; Mon, 20 Oct 2003 13:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeEI-0002pF-00; Mon, 20 Oct 2003 13:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeED-0000Qj-9B; Mon, 20 Oct 2003 13:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeDU-0000HN-BU for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:53:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05558 for ; Mon, 20 Oct 2003 13:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeDS-0002oh-00 for simple@ietf.org; Mon, 20 Oct 2003 13:53:14 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABeDR-0002od-00 for simple@ietf.org; Mon, 20 Oct 2003 13:53:13 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KHr4F8010872; Mon, 20 Oct 2003 12:53:10 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F9420EE.8000200@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP Comments - Keepalive References: <2038BCC78B1AD641891A0D1AE133DBB7017972BC@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972BC@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 12:52:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I will re-iterate that I do not see this as overloading method semantics. The relays do not even know that keepalives exist--nor should they. All they are doing is watching how much time has passed since the last SEND request. I believe the empty SEND request was the consensus of the room in the interim meeting. Are there others that share the opinion that we need to change this to a new method? hisham.khartabil@nokia.com wrote: > I'm in favour of not overloading method semantics and therefore agree with Aki. > > KEEPALIVE sounds ok. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext aki.niemi@nokia.com >>Sent: Monday, October 20, 2003 1:03 PM >>To: bcampbell@dynamicsoft.com >>Cc: simple@ietf.org >>Subject: RE: [Simple] MSRP Comments - Keepalive >> >> >> >> >> > -----Original Message----- >> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> > Sent: 17 October, 2003 20:49 >> > To: Niemi Aki (NMP/Helsinki) >> > Cc: simple@ietf.org >> > Subject: Re: [Simple] MSRP Comments - Keepalive >> > >> > >> > The reasoning was, from a relay's perspective, it watchers for IM >> > traffic to determine liveness. Clients that don't have any _other_ >> > traffic to send should just generate some frome time to >> > time. There is >> > nothing particularly special about the traffic generated. >>Sending an >> > empty message seemed to have exactly these semantics. >> >>I don't think there is anything wrong with this reasoning. >> >> > From an endpoints perspective, I could see adding a new >> > method if we >> > wanted some special semantic handling that is different than >> > for SEND. >> > But I don't see how the receiver semantics for a >>"KEEPALIVE" method >> > would be any different than for an empty SEND method. >> >>That is certainly true. I don't think there is a difference >>in semantics. >> >>Where I think something like KEEPALIVE would help is in >>specification clarity. I think it's better to keep things >>explicit. If in total, this would save a few posts on >>sip-implementors that doubt the "special" nature of a SEND >>without a body, then I think it's worth doing. >> >>On the other hand, as a drawback to the KEEPALIVE method, it >>would require defining a new method with it's associated >>specification work, which I don't believe is a considerable >>burden though. Is there any other reason to prefer an empty >>SEND over a KEEPALIVE? >> >>Regards, >>Aki >> >> > >> > Aki Niemi wrote: >> > >> > > Hi, >> > > >> > > I know this is the sort of thing people usually use as >> > flamebait, but I >> > > just have to ask ;-) >> > > >> > > Why overload the SEND for keepalive? Is there a specific >>reason to >> > > minimize the number of methods in this protocol? I don't see the >> > > complexity added by having a function that clearly does >>something >> > > specific have its own method name, too. >> > > >> > > Regards, >> > > Aki >> > > >> > > >> > > >> > > _______________________________________________ >> > > Simple mailing list >> > > Simple@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/simple >> > >> > >> > >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:06:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06142; Mon, 20 Oct 2003 14:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeQ3-0002yk-00; Mon, 20 Oct 2003 14:06:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeQ2-0002yh-00; Mon, 20 Oct 2003 14:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABePp-0003wn-Ji; Mon, 20 Oct 2003 14:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABePJ-0003qh-Hh for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:05:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06125 for ; Mon, 20 Oct 2003 14:05:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABePG-0002y8-00 for simple@ietf.org; Mon, 20 Oct 2003 14:05:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABePG-0002y5-00 for simple@ietf.org; Mon, 20 Oct 2003 14:05:26 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KI5Od18674 for ; Mon, 20 Oct 2003 21:05:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:05:24 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 21:05:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 21:05:23 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on MSRP - multiparty message session support X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BE@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOXDwDociw7YJZwS7mc9nqUEzAefQAJXAYg To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 18:05:23.0270 (UTC) FILETIME=[BB48A660:01C39734] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:05:23 +0300 Content-Transfer-Encoding: quoted-printable This is very much inline with Pekka's suggestion and I like it. I vote for mandating message/cpim. Of course, we still need to signal = what mime-types an endpoint supports, using SDP. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: Monday, October 20, 2003 4:31 PM > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on MSRP - multiparty message session > support >=20 >=20 > aki.niemi@nokia.com wrote: >=20 > >=20 > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: 17 October, 2003 20:36 > > > To: Niemi Aki (NMP/Helsinki) > > > Cc: simple@ietf.org > > > Subject: Re: [Simple] Comments on MSRP - multiparty=20 > message session > > > support > > >=20 > > >=20 > > > We talked about how this could be done in a couple of ways.=20 > > > One was by=20 > > > simply having the mixer remember the identity associated=20 > with each=20 > > > connection. > >=20 > > This would still not work, since there isn't a vehicle in=20 > the protocol to transport this "asserted-identity" to the=20 > recipient endpoints. > > =20 > > > The mixer could also insist that all content be wrapped in=20 > > > message/cpim=20 > > > using our extension to the SDP format list negotiation. > >=20 > > Which is fine, if all MSRP endpoints are required to=20 > support it. Currently they aren't which potentially leaves a=20 > lot of MSRP clients incapable of participating in message=20 > session conferences. >=20 > I am not opposed to requiring support for this. In=20 > retrospect, I think=20 > we intended to do that and it just didn't make it in. >=20 > >=20 > > Regards, > > Aki > >=20 > > > Aki Niemi wrote: > > >=20 > > > > Hi All, > > > >=20 > > > > Since MSGFMT is no longer mandated (or is but only for=20 > > > CPIM gateways),=20 > > > > how would a participant know where a message is coming=20 > from in a=20 > > > > multiparty message session? > > > >=20 > > > > Also, when using MSRP in a conferencing system, the lack=20 > > > of To/From=20 > > > > prevents sending private messages efficiently within a=20 > multiparty=20 > > > > session using an MSRP mixer as a "router" for them. > > > >=20 > > > > So my question is this: what is the extensibility model=20 > > > for MSRP? For=20 > > > > example, would it be possible to later on add this multiparty=20 > > > > functionality as an extension, or would it be wise to=20 > think ahead=20 > > > > already now? > > > >=20 > > > > The draft includes some extensibility, e.g., for=20 > authentication=20 > > > > algorithms, but I didn't immediately find much about=20 > > > adding methods and=20 > > > > headers, and what to do with unknown headers. > > > >=20 > > > > Regards, > > > > Aki > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 14:06:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06170 for ; Mon, 20 Oct 2003 14:06:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeQ6-00043R-Dn for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:06:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KI6IjO015579 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeQ6-00043C-99 for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:06:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06142; Mon, 20 Oct 2003 14:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeQ3-0002yk-00; Mon, 20 Oct 2003 14:06:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeQ2-0002yh-00; Mon, 20 Oct 2003 14:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABePp-0003wn-Ji; Mon, 20 Oct 2003 14:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABePJ-0003qh-Hh for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:05:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06125 for ; Mon, 20 Oct 2003 14:05:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABePG-0002y8-00 for simple@ietf.org; Mon, 20 Oct 2003 14:05:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABePG-0002y5-00 for simple@ietf.org; Mon, 20 Oct 2003 14:05:26 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KI5Od18674 for ; Mon, 20 Oct 2003 21:05:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:05:24 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 21:05:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 21:05:23 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on MSRP - multiparty message session support X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BE@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOXDwDociw7YJZwS7mc9nqUEzAefQAJXAYg To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 18:05:23.0270 (UTC) FILETIME=[BB48A660:01C39734] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:05:23 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is very much inline with Pekka's suggestion and I like it. I vote for mandating message/cpim. Of course, we still need to signal = what mime-types an endpoint supports, using SDP. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: Monday, October 20, 2003 4:31 PM > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on MSRP - multiparty message session > support >=20 >=20 > aki.niemi@nokia.com wrote: >=20 > >=20 > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: 17 October, 2003 20:36 > > > To: Niemi Aki (NMP/Helsinki) > > > Cc: simple@ietf.org > > > Subject: Re: [Simple] Comments on MSRP - multiparty=20 > message session > > > support > > >=20 > > >=20 > > > We talked about how this could be done in a couple of ways.=20 > > > One was by=20 > > > simply having the mixer remember the identity associated=20 > with each=20 > > > connection. > >=20 > > This would still not work, since there isn't a vehicle in=20 > the protocol to transport this "asserted-identity" to the=20 > recipient endpoints. > > =20 > > > The mixer could also insist that all content be wrapped in=20 > > > message/cpim=20 > > > using our extension to the SDP format list negotiation. > >=20 > > Which is fine, if all MSRP endpoints are required to=20 > support it. Currently they aren't which potentially leaves a=20 > lot of MSRP clients incapable of participating in message=20 > session conferences. >=20 > I am not opposed to requiring support for this. In=20 > retrospect, I think=20 > we intended to do that and it just didn't make it in. >=20 > >=20 > > Regards, > > Aki > >=20 > > > Aki Niemi wrote: > > >=20 > > > > Hi All, > > > >=20 > > > > Since MSGFMT is no longer mandated (or is but only for=20 > > > CPIM gateways),=20 > > > > how would a participant know where a message is coming=20 > from in a=20 > > > > multiparty message session? > > > >=20 > > > > Also, when using MSRP in a conferencing system, the lack=20 > > > of To/From=20 > > > > prevents sending private messages efficiently within a=20 > multiparty=20 > > > > session using an MSRP mixer as a "router" for them. > > > >=20 > > > > So my question is this: what is the extensibility model=20 > > > for MSRP? For=20 > > > > example, would it be possible to later on add this multiparty=20 > > > > functionality as an extension, or would it be wise to=20 > think ahead=20 > > > > already now? > > > >=20 > > > > The draft includes some extensibility, e.g., for=20 > authentication=20 > > > > algorithms, but I didn't immediately find much about=20 > > > adding methods and=20 > > > > headers, and what to do with unknown headers. > > > >=20 > > > > Regards, > > > > Aki > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:11:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06264; Mon, 20 Oct 2003 14:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeVg-00030p-00; Mon, 20 Oct 2003 14:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeVf-00030m-00; Mon, 20 Oct 2003 14:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeVd-0006Ez-PG; Mon, 20 Oct 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeVE-0006A6-9c for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:11:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06260 for ; Mon, 20 Oct 2003 14:11:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeVB-00030h-00 for simple@ietf.org; Mon, 20 Oct 2003 14:11:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABeVB-00030Z-00 for simple@ietf.org; Mon, 20 Oct 2003 14:11:33 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2003 11:07:50 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9KIAxQY003476; Mon, 20 Oct 2003 11:11:00 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH62822; Mon, 20 Oct 2003 14:10:59 -0400 (EDT) Message-ID: <3F942533.1000303@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> <3F941D61.2090800@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 14:10:59 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>> Having a response delayed by a long request in the recipricol >>> direction is a problem I don't think we have considered. I welcome >>> input as to whether we think this is a real issue, and if so, how to >>> deal with it. >> >> I thought we agreed that large messages should be sent using a >> separate session. Or we change that decision? If not, I cannot recall >> if there was a threshold that classifies as message as large. > > You are correct, we have text encouraging this behavior. Since you > reminded me of this, and no one else jumped in to say that this is a big > problem, I am going to assume for now that it is not. If anyone feels > otherwise, please jump in asap. I'm not sure if that solves the problem. It just moves it to the separate session. I guess it goes away if we assume that each and every large message should get its very own session, but that doesn't sound like a wonderful solution. Perhaps a session intended for large messages should not be used to initiate messages (large or small) in the reverse direction. So, I can create a special stream to send files to you, and pour several files thru it. But if you have files to send to me then you should set up a separate stream. That of course punts the question of how the two ends agree on the intended use of a stream. Just because I establish the stream with the intent of sending large messages to you, that doesn't mean you know that. If you don't you might start sending small messages to me over it. Maybe we need some sort of purpose attribute, or a maximum size attribute, that can be specified/negotiated during session establishment. One answer might be to use a=sendonly to indicate a stream that should only be used in one direction. On such a stream only responses would be permitted in the reverse direction. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 14:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06281 for ; Mon, 20 Oct 2003 14:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeVj-0006Hm-IL for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KIC7cM024156 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeVj-0006HX-8H for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:12:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06264; Mon, 20 Oct 2003 14:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeVg-00030p-00; Mon, 20 Oct 2003 14:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeVf-00030m-00; Mon, 20 Oct 2003 14:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeVd-0006Ez-PG; Mon, 20 Oct 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeVE-0006A6-9c for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:11:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06260 for ; Mon, 20 Oct 2003 14:11:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeVB-00030h-00 for simple@ietf.org; Mon, 20 Oct 2003 14:11:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABeVB-00030Z-00 for simple@ietf.org; Mon, 20 Oct 2003 14:11:33 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2003 11:07:50 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9KIAxQY003476; Mon, 20 Oct 2003 11:11:00 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH62822; Mon, 20 Oct 2003 14:10:59 -0400 (EDT) Message-ID: <3F942533.1000303@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> <3F941D61.2090800@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 14:10:59 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>> Having a response delayed by a long request in the recipricol >>> direction is a problem I don't think we have considered. I welcome >>> input as to whether we think this is a real issue, and if so, how to >>> deal with it. >> >> I thought we agreed that large messages should be sent using a >> separate session. Or we change that decision? If not, I cannot recall >> if there was a threshold that classifies as message as large. > > You are correct, we have text encouraging this behavior. Since you > reminded me of this, and no one else jumped in to say that this is a big > problem, I am going to assume for now that it is not. If anyone feels > otherwise, please jump in asap. I'm not sure if that solves the problem. It just moves it to the separate session. I guess it goes away if we assume that each and every large message should get its very own session, but that doesn't sound like a wonderful solution. Perhaps a session intended for large messages should not be used to initiate messages (large or small) in the reverse direction. So, I can create a special stream to send files to you, and pour several files thru it. But if you have files to send to me then you should set up a separate stream. That of course punts the question of how the two ends agree on the intended use of a stream. Just because I establish the stream with the intent of sending large messages to you, that doesn't mean you know that. If you don't you might start sending small messages to me over it. Maybe we need some sort of purpose attribute, or a maximum size attribute, that can be specified/negotiated during session establishment. One answer might be to use a=sendonly to indicate a stream that should only be used in one direction. On such a stream only responses would be permitted in the reverse direction. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:17:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06400; Mon, 20 Oct 2003 14:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeaf-000348-00; Mon, 20 Oct 2003 14:17:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeae-000345-00; Mon, 20 Oct 2003 14:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeaT-0007vj-Lf; Mon, 20 Oct 2003 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeZx-0007mg-Nz for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:16:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06368 for ; Mon, 20 Oct 2003 14:16:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeZv-00033e-00 for simple@ietf.org; Mon, 20 Oct 2003 14:16:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABeZu-00033b-00 for simple@ietf.org; Mon, 20 Oct 2003 14:16:26 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KIGPd28586 for ; Mon, 20 Oct 2003 21:16:25 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:16:24 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 21:16:24 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BF@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOXNYc7upbfF7O8Q5OrtnLduMtSgwAAG/tg To: , Cc: , X-OriginalArrivalTime: 20 Oct 2003 18:16:24.0800 (UTC) FILETIME=[45961E00:01C39736] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:16:24 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, October 20, 2003 9:11 PM > To: Ben Campbell > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > simple@ietf.org > Subject: Re: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > >>> Having a response delayed by a long request in the recipricol=20 > >>> direction is a problem I don't think we have considered.=20 > I welcome=20 > >>> input as to whether we think this is a real issue, and if=20 > so, how to=20 > >>> deal with it. > >> > >> I thought we agreed that large messages should be sent using a=20 > >> separate session. Or we change that decision? If not, I=20 > cannot recall=20 > >> if there was a threshold that classifies as message as large. > >=20 > > You are correct, we have text encouraging this behavior. Since you=20 > > reminded me of this, and no one else jumped in to say that=20 > this is a big=20 > > problem, I am going to assume for now that it is not. If=20 > anyone feels=20 > > otherwise, please jump in asap. >=20 > I'm not sure if that solves the problem. It just moves it to the=20 > separate session. I guess it goes away if we assume that each=20 > and every=20 > large message should get its very own session, but that doesn't sound=20 > like a wonderful solution. >=20 > Perhaps a session intended for large messages should not be used to=20 > initiate messages (large or small) in the reverse direction.=20 > So, I can=20 > create a special stream to send files to you, and pour several files=20 > thru it. But if you have files to send to me then you should set up a=20 > separate stream. >=20 > That of course punts the question of how the two ends agree on the=20 > intended use of a stream. Just because I establish the stream=20 > with the=20 > intent of sending large messages to you, that doesn't mean you know=20 > that. If you don't you might start sending small messages to=20 > me over it. >=20 > Maybe we need some sort of purpose attribute, or a maximum size=20 > attribute, that can be specified/negotiated during session=20 > establishment. One answer might be to use a=3Dsendonly to indicate a=20 > stream that should only be used in one direction. On such a=20 > stream only=20 > responses would be permitted in the reverse direction. Yes, I was already thinking of this type of solution after reading your = third paragraph above :) I don't think there is a need for max size = attribute if we have a direction attribute as you suggest. /Hisham >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 14:17:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06424 for ; Mon, 20 Oct 2003 14:17:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeai-00081H-1w for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:17:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KIHGTq030817 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeah-00080y-U8 for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:17:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06400; Mon, 20 Oct 2003 14:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeaf-000348-00; Mon, 20 Oct 2003 14:17:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeae-000345-00; Mon, 20 Oct 2003 14:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeaT-0007vj-Lf; Mon, 20 Oct 2003 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeZx-0007mg-Nz for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:16:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06368 for ; Mon, 20 Oct 2003 14:16:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeZv-00033e-00 for simple@ietf.org; Mon, 20 Oct 2003 14:16:27 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABeZu-00033b-00 for simple@ietf.org; Mon, 20 Oct 2003 14:16:26 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KIGPd28586 for ; Mon, 20 Oct 2003 21:16:25 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:16:24 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 21:16:24 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972BF@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOXNYc7upbfF7O8Q5OrtnLduMtSgwAAG/tg To: , Cc: , X-OriginalArrivalTime: 20 Oct 2003 18:16:24.0800 (UTC) FILETIME=[45961E00:01C39736] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:16:24 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, October 20, 2003 9:11 PM > To: Ben Campbell > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > simple@ietf.org > Subject: Re: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > >>> Having a response delayed by a long request in the recipricol=20 > >>> direction is a problem I don't think we have considered.=20 > I welcome=20 > >>> input as to whether we think this is a real issue, and if=20 > so, how to=20 > >>> deal with it. > >> > >> I thought we agreed that large messages should be sent using a=20 > >> separate session. Or we change that decision? If not, I=20 > cannot recall=20 > >> if there was a threshold that classifies as message as large. > >=20 > > You are correct, we have text encouraging this behavior. Since you=20 > > reminded me of this, and no one else jumped in to say that=20 > this is a big=20 > > problem, I am going to assume for now that it is not. If=20 > anyone feels=20 > > otherwise, please jump in asap. >=20 > I'm not sure if that solves the problem. It just moves it to the=20 > separate session. I guess it goes away if we assume that each=20 > and every=20 > large message should get its very own session, but that doesn't sound=20 > like a wonderful solution. >=20 > Perhaps a session intended for large messages should not be used to=20 > initiate messages (large or small) in the reverse direction.=20 > So, I can=20 > create a special stream to send files to you, and pour several files=20 > thru it. But if you have files to send to me then you should set up a=20 > separate stream. >=20 > That of course punts the question of how the two ends agree on the=20 > intended use of a stream. Just because I establish the stream=20 > with the=20 > intent of sending large messages to you, that doesn't mean you know=20 > that. If you don't you might start sending small messages to=20 > me over it. >=20 > Maybe we need some sort of purpose attribute, or a maximum size=20 > attribute, that can be specified/negotiated during session=20 > establishment. One answer might be to use a=3Dsendonly to indicate a=20 > stream that should only be used in one direction. On such a=20 > stream only=20 > responses would be permitted in the reverse direction. Yes, I was already thinking of this type of solution after reading your = third paragraph above :) I don't think there is a need for max size = attribute if we have a direction attribute as you suggest. /Hisham >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:17:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04794; Mon, 20 Oct 2003 13:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdr5-0002ba-00; Mon, 20 Oct 2003 13:30:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdr4-0002bU-00; Mon, 20 Oct 2003 13:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdr0-0002Tv-CF; Mon, 20 Oct 2003 13:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqp-0002Ry-36 for simple@optimus.ietf.org; Mon, 20 Oct 2003 13:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04749 for ; Mon, 20 Oct 2003 13:29:40 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqn-0002az-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqm-0002aq-00 for simple@ietf.org; Mon, 20 Oct 2003 13:29:48 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KHTfd13001 for ; Mon, 20 Oct 2003 20:29:41 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 20:29:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 20:29:40 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOU1o4IMBXRwzxIThOAGbVc14rbfACQ71Pg To: , Cc: X-OriginalArrivalTime: 20 Oct 2003 17:29:40.0476 (UTC) FILETIME=[BE143BC0:01C3972F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 20:29:40 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, October 17, 2003 8:44 PM > To: Niemi Aki (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 > Based on recent discussions, I think we may need to rethink this. The=20 > point to resending was _not_ to build a reliability mechanism=20 > on top of=20 > TCP. We really wanted a mechanism to simply warn the user if we could=20 > not be sure the opposite endpoint had actually processed the=20 > message. I=20 > think we should either remove the text encouraging re-submission, or=20 > change it to re-use the same TR-ID, and add text to describe what the=20 > peer should do if it sees duplicate TR-IDs. I would hate to resend a 5gb message. I think there should be a timer = for the response, without retransmissions. If the timer fires, then you = have to assume that something went wrong in delivering the message. = Retransmission won't help. >=20 > Having a response delayed by a long request in the recipricol=20 > direction=20 > is a problem I don't think we have considered. I welcome input as to=20 > whether we think this is a real issue, and if so, how to deal with it. I thought we agreed that large messages should be sent using a separate = session. Or we change that decision? If not, I cannot recall if there = was a threshold that classifies as message as large. /Hisham >=20 > Aki Niemi wrote: >=20 > > Hi, > >=20 > > In the draft, if a SEND times out, the MSRP client is=20 > supposed to handle=20 > > this as if a 5xx was received. I.e., it will resend the=20 > message a few=20 > > times and then quit the session. In case the other endpoint=20 > is in the=20 > > midst of sending a large message, a response may take =20 > longer than the=20 > > request time out value. This will result in a number of duplicate=20 > > messages received. There should be a better way to handle this. Why=20 > > resend in the first place, especially if the connection is active? > >=20 > > Also, what is the motivation for making retransmissions=20 > with a different=20 > > TR-ID? Doesn't this go agains the idea of retrying the request? > >=20 > > Regards, > > Aki > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:20:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06514; Mon, 20 Oct 2003 14:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeeM-00036H-00; Mon, 20 Oct 2003 14:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeeL-00036E-00; Mon, 20 Oct 2003 14:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeeM-0000U6-CU; Mon, 20 Oct 2003 14:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeeB-0000Qz-80 for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06504 for ; Mon, 20 Oct 2003 14:20:41 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABee8-00035y-00 for simple@ietf.org; Mon, 20 Oct 2003 14:20:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABee7-00035v-00 for simple@ietf.org; Mon, 20 Oct 2003 14:20:48 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KIKkd01972 for ; Mon, 20 Oct 2003 21:20:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:20:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 21:20:46 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972C1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOXNYc7upbfF7O8Q5OrtnLduMtSgwAAG/tgAAAvUOA= To: , , Cc: , X-OriginalArrivalTime: 20 Oct 2003 18:20:46.0477 (UTC) FILETIME=[E18EDBD0:01C39736] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:20:45 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: Monday, October 20, 2003 9:16 PM > To: pkyzivat@cisco.com; bcampbell@dynamicsoft.com > Cc: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, October 20, 2003 9:11 PM > > To: Ben Campbell > > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > > simple@ietf.org > > Subject: Re: [Simple] MSRP comments - request/response handling and > > retrying > >=20 > >=20 > >=20 > >=20 > > Ben Campbell wrote: > > >=20 > > >>> Having a response delayed by a long request in the recipricol=20 > > >>> direction is a problem I don't think we have considered.=20 > > I welcome=20 > > >>> input as to whether we think this is a real issue, and if=20 > > so, how to=20 > > >>> deal with it. > > >> > > >> I thought we agreed that large messages should be sent using a=20 > > >> separate session. Or we change that decision? If not, I=20 > > cannot recall=20 > > >> if there was a threshold that classifies as message as large. > > >=20 > > > You are correct, we have text encouraging this behavior.=20 > Since you=20 > > > reminded me of this, and no one else jumped in to say that=20 > > this is a big=20 > > > problem, I am going to assume for now that it is not. If=20 > > anyone feels=20 > > > otherwise, please jump in asap. > >=20 > > I'm not sure if that solves the problem. It just moves it to the=20 > > separate session. I guess it goes away if we assume that each=20 > > and every=20 > > large message should get its very own session, but that=20 > doesn't sound=20 > > like a wonderful solution. > >=20 > > Perhaps a session intended for large messages should not be used to=20 > > initiate messages (large or small) in the reverse direction.=20 > > So, I can=20 > > create a special stream to send files to you, and pour=20 > several files=20 > > thru it. But if you have files to send to me then you=20 > should set up a=20 > > separate stream. > >=20 > > That of course punts the question of how the two ends agree on the=20 > > intended use of a stream. Just because I establish the stream=20 > > with the=20 > > intent of sending large messages to you, that doesn't mean you know=20 > > that. If you don't you might start sending small messages to=20 > > me over it. > >=20 > > Maybe we need some sort of purpose attribute, or a maximum size=20 > > attribute, that can be specified/negotiated during session=20 > > establishment. One answer might be to use a=3Dsendonly to indicate a = > > stream that should only be used in one direction. On such a=20 > > stream only=20 > > responses would be permitted in the reverse direction. >=20 > Yes, I was already thinking of this type of solution after=20 > reading your third paragraph above :) I don't think there is=20 > a need for max size attribute if we have a direction=20 > attribute as you suggest. Of course, I don't mean the direction attribute we have now (passive vs. = active), but the sendonly. >=20 > /Hisham >=20 >=20 > >=20 > > Paul > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 14:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06536 for ; Mon, 20 Oct 2003 14:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeeP-0000XI-6l for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KIL5QD002054 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeeP-0000Ww-3T for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06514; Mon, 20 Oct 2003 14:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeeM-00036H-00; Mon, 20 Oct 2003 14:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABeeL-00036E-00; Mon, 20 Oct 2003 14:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeeM-0000U6-CU; Mon, 20 Oct 2003 14:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeeB-0000Qz-80 for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06504 for ; Mon, 20 Oct 2003 14:20:41 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABee8-00035y-00 for simple@ietf.org; Mon, 20 Oct 2003 14:20:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABee7-00035v-00 for simple@ietf.org; Mon, 20 Oct 2003 14:20:48 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KIKkd01972 for ; Mon, 20 Oct 2003 21:20:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:20:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 21:20:46 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972C1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOXNYc7upbfF7O8Q5OrtnLduMtSgwAAG/tgAAAvUOA= To: , , Cc: , X-OriginalArrivalTime: 20 Oct 2003 18:20:46.0477 (UTC) FILETIME=[E18EDBD0:01C39736] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:20:45 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: Monday, October 20, 2003 9:16 PM > To: pkyzivat@cisco.com; bcampbell@dynamicsoft.com > Cc: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, October 20, 2003 9:11 PM > > To: Ben Campbell > > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > > simple@ietf.org > > Subject: Re: [Simple] MSRP comments - request/response handling and > > retrying > >=20 > >=20 > >=20 > >=20 > > Ben Campbell wrote: > > >=20 > > >>> Having a response delayed by a long request in the recipricol=20 > > >>> direction is a problem I don't think we have considered.=20 > > I welcome=20 > > >>> input as to whether we think this is a real issue, and if=20 > > so, how to=20 > > >>> deal with it. > > >> > > >> I thought we agreed that large messages should be sent using a=20 > > >> separate session. Or we change that decision? If not, I=20 > > cannot recall=20 > > >> if there was a threshold that classifies as message as large. > > >=20 > > > You are correct, we have text encouraging this behavior.=20 > Since you=20 > > > reminded me of this, and no one else jumped in to say that=20 > > this is a big=20 > > > problem, I am going to assume for now that it is not. If=20 > > anyone feels=20 > > > otherwise, please jump in asap. > >=20 > > I'm not sure if that solves the problem. It just moves it to the=20 > > separate session. I guess it goes away if we assume that each=20 > > and every=20 > > large message should get its very own session, but that=20 > doesn't sound=20 > > like a wonderful solution. > >=20 > > Perhaps a session intended for large messages should not be used to=20 > > initiate messages (large or small) in the reverse direction.=20 > > So, I can=20 > > create a special stream to send files to you, and pour=20 > several files=20 > > thru it. But if you have files to send to me then you=20 > should set up a=20 > > separate stream. > >=20 > > That of course punts the question of how the two ends agree on the=20 > > intended use of a stream. Just because I establish the stream=20 > > with the=20 > > intent of sending large messages to you, that doesn't mean you know=20 > > that. If you don't you might start sending small messages to=20 > > me over it. > >=20 > > Maybe we need some sort of purpose attribute, or a maximum size=20 > > attribute, that can be specified/negotiated during session=20 > > establishment. One answer might be to use a=3Dsendonly to indicate a = > > stream that should only be used in one direction. On such a=20 > > stream only=20 > > responses would be permitted in the reverse direction. >=20 > Yes, I was already thinking of this type of solution after=20 > reading your third paragraph above :) I don't think there is=20 > a need for max size attribute if we have a direction=20 > attribute as you suggest. Of course, I don't mean the direction attribute we have now (passive vs. = active), but the sendonly. >=20 > /Hisham >=20 >=20 > >=20 > > Paul > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:26:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06714; Mon, 20 Oct 2003 14:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABejK-00039V-00; Mon, 20 Oct 2003 14:26:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABejK-00039S-00; Mon, 20 Oct 2003 14:26:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABejB-0001x6-2F; Mon, 20 Oct 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeix-0001rw-EL for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:25:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06704 for ; Mon, 20 Oct 2003 14:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeiu-00039B-00 for simple@ietf.org; Mon, 20 Oct 2003 14:25:44 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABeit-000398-00 for simple@ietf.org; Mon, 20 Oct 2003 14:25:44 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KIPaF8013655; Mon, 20 Oct 2003 13:25:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F94288E.3040403@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: <2038BCC78B1AD641891A0D1AE133DBB7017972BE@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972BE@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:25:18 -0500 Content-Transfer-Encoding: 7bit Just to be sure that we are clear on this, I agree that we should mandate _support_. _Use_ is still up to the endpoints to negotiated. I think this accomplishes what we need, without encumbering simple point-to-point sessions with the extra overhead. hisham.khartabil@nokia.com wrote: > This is very much inline with Pekka's suggestion and I like it. > > I vote for mandating message/cpim. Of course, we still need to signal what mime-types an endpoint supports, using SDP. > > /Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: Monday, October 20, 2003 4:31 PM >>To: Niemi Aki (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on MSRP - multiparty message session >>support >> >> >>aki.niemi@nokia.com wrote: >> >> >>> > -----Original Message----- >>> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> > Sent: 17 October, 2003 20:36 >>> > To: Niemi Aki (NMP/Helsinki) >>> > Cc: simple@ietf.org >>> > Subject: Re: [Simple] Comments on MSRP - multiparty >> >>message session >> >>> > support >>> > >>> > >>> > We talked about how this could be done in a couple of ways. >>> > One was by >>> > simply having the mixer remember the identity associated >> >>with each >> >>> > connection. >>> >>>This would still not work, since there isn't a vehicle in >> >>the protocol to transport this "asserted-identity" to the >>recipient endpoints. >> >>> >>> > The mixer could also insist that all content be wrapped in >>> > message/cpim >>> > using our extension to the SDP format list negotiation. >>> >>>Which is fine, if all MSRP endpoints are required to >> >>support it. Currently they aren't which potentially leaves a >>lot of MSRP clients incapable of participating in message >>session conferences. >> >>I am not opposed to requiring support for this. In >>retrospect, I think >>we intended to do that and it just didn't make it in. >> >> >>>Regards, >>>Aki >>> >>> > Aki Niemi wrote: >>> > >>> > > Hi All, >>> > > >>> > > Since MSGFMT is no longer mandated (or is but only for >>> > CPIM gateways), >>> > > how would a participant know where a message is coming >> >>from in a >> >>> > > multiparty message session? >>> > > >>> > > Also, when using MSRP in a conferencing system, the lack >>> > of To/From >>> > > prevents sending private messages efficiently within a >> >>multiparty >> >>> > > session using an MSRP mixer as a "router" for them. >>> > > >>> > > So my question is this: what is the extensibility model >>> > for MSRP? For >>> > > example, would it be possible to later on add this multiparty >>> > > functionality as an extension, or would it be wise to >> >>think ahead >> >>> > > already now? >>> > > >>> > > The draft includes some extensibility, e.g., for >> >>authentication >> >>> > > algorithms, but I didn't immediately find much about >>> > adding methods and >>> > > headers, and what to do with unknown headers. >>> > > >>> > > Regards, >>> > > Aki >>> > > >>> > > >>> > > _______________________________________________ >>> > > Simple mailing list >>> > > Simple@ietf.org >>> > > https://www1.ietf.org/mailman/listinfo/simple >>> > >>> > >>> > >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 14:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06753 for ; Mon, 20 Oct 2003 14:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABejN-00022W-Ip for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:26:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KIQDox007834 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABejN-00022H-FV for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06714; Mon, 20 Oct 2003 14:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABejK-00039V-00; Mon, 20 Oct 2003 14:26:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABejK-00039S-00; Mon, 20 Oct 2003 14:26:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABejB-0001x6-2F; Mon, 20 Oct 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABeix-0001rw-EL for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:25:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06704 for ; Mon, 20 Oct 2003 14:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABeiu-00039B-00 for simple@ietf.org; Mon, 20 Oct 2003 14:25:44 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABeit-000398-00 for simple@ietf.org; Mon, 20 Oct 2003 14:25:44 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9KIPaF8013655; Mon, 20 Oct 2003 13:25:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F94288E.3040403@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on MSRP - multiparty message session support References: <2038BCC78B1AD641891A0D1AE133DBB7017972BE@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017972BE@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 13:25:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just to be sure that we are clear on this, I agree that we should mandate _support_. _Use_ is still up to the endpoints to negotiated. I think this accomplishes what we need, without encumbering simple point-to-point sessions with the extra overhead. hisham.khartabil@nokia.com wrote: > This is very much inline with Pekka's suggestion and I like it. > > I vote for mandating message/cpim. Of course, we still need to signal what mime-types an endpoint supports, using SDP. > > /Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: Monday, October 20, 2003 4:31 PM >>To: Niemi Aki (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on MSRP - multiparty message session >>support >> >> >>aki.niemi@nokia.com wrote: >> >> >>> > -----Original Message----- >>> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> > Sent: 17 October, 2003 20:36 >>> > To: Niemi Aki (NMP/Helsinki) >>> > Cc: simple@ietf.org >>> > Subject: Re: [Simple] Comments on MSRP - multiparty >> >>message session >> >>> > support >>> > >>> > >>> > We talked about how this could be done in a couple of ways. >>> > One was by >>> > simply having the mixer remember the identity associated >> >>with each >> >>> > connection. >>> >>>This would still not work, since there isn't a vehicle in >> >>the protocol to transport this "asserted-identity" to the >>recipient endpoints. >> >>> >>> > The mixer could also insist that all content be wrapped in >>> > message/cpim >>> > using our extension to the SDP format list negotiation. >>> >>>Which is fine, if all MSRP endpoints are required to >> >>support it. Currently they aren't which potentially leaves a >>lot of MSRP clients incapable of participating in message >>session conferences. >> >>I am not opposed to requiring support for this. In >>retrospect, I think >>we intended to do that and it just didn't make it in. >> >> >>>Regards, >>>Aki >>> >>> > Aki Niemi wrote: >>> > >>> > > Hi All, >>> > > >>> > > Since MSGFMT is no longer mandated (or is but only for >>> > CPIM gateways), >>> > > how would a participant know where a message is coming >> >>from in a >> >>> > > multiparty message session? >>> > > >>> > > Also, when using MSRP in a conferencing system, the lack >>> > of To/From >>> > > prevents sending private messages efficiently within a >> >>multiparty >> >>> > > session using an MSRP mixer as a "router" for them. >>> > > >>> > > So my question is this: what is the extensibility model >>> > for MSRP? For >>> > > example, would it be possible to later on add this multiparty >>> > > functionality as an extension, or would it be wise to >> >>think ahead >> >>> > > already now? >>> > > >>> > > The draft includes some extensibility, e.g., for >> >>authentication >> >>> > > algorithms, but I didn't immediately find much about >>> > adding methods and >>> > > headers, and what to do with unknown headers. >>> > > >>> > > Regards, >>> > > Aki >>> > > >>> > > >>> > > _______________________________________________ >>> > > Simple mailing list >>> > > Simple@ietf.org >>> > > https://www1.ietf.org/mailman/listinfo/simple >>> > >>> > >>> > >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 20 14:29:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06873; Mon, 20 Oct 2003 14:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABen5-0003CN-00; Mon, 20 Oct 2003 14:30:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABen4-0003CK-00; Mon, 20 Oct 2003 14:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABen3-0003BY-TK; Mon, 20 Oct 2003 14:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABemi-00030u-On for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:29:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06858 for ; Mon, 20 Oct 2003 14:29:30 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABemg-0003Bz-00 for simple@ietf.org; Mon, 20 Oct 2003 14:29:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABemf-0003Bw-00 for simple@ietf.org; Mon, 20 Oct 2003 14:29:37 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KITad09144 for ; Mon, 20 Oct 2003 21:29:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:29:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 21:29:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on MSRP - multiparty message session support X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972C4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOXN5jfiGedKPJTSTKNfVp3XbAL7QAAFUgw To: Cc: , X-OriginalArrivalTime: 20 Oct 2003 18:29:35.0801 (UTC) FILETIME=[1D0F4A90:01C39738] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:29:35 +0300 Content-Transfer-Encoding: quoted-printable Yes, just support. If a conference server wants message/cpim, it = indicates so in the offer or answer (dial out and dial in cases) /Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, October 20, 2003 9:25 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] Comments on MSRP - multiparty message session > support >=20 >=20 > Just to be sure that we are clear on this, I agree that we should=20 > mandate _support_. _Use_ is still up to the endpoints to=20 > negotiated. I=20 > think this accomplishes what we need, without encumbering simple=20 > point-to-point sessions with the extra overhead. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > This is very much inline with Pekka's suggestion and I like it. > >=20 > > I vote for mandating message/cpim. Of course, we still need=20 > to signal what mime-types an endpoint supports, using SDP. > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: Monday, October 20, 2003 4:31 PM > >>To: Niemi Aki (NMP/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] Comments on MSRP - multiparty message session > >>support > >> > >> > >>aki.niemi@nokia.com wrote: > >> > >> > >>> > -----Original Message----- > >>> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> > Sent: 17 October, 2003 20:36 > >>> > To: Niemi Aki (NMP/Helsinki) > >>> > Cc: simple@ietf.org > >>> > Subject: Re: [Simple] Comments on MSRP - multiparty=20 > >> > >>message session > >> > >>> > support > >>> >=20 > >>> >=20 > >>> > We talked about how this could be done in a couple of ways.=20 > >>> > One was by=20 > >>> > simply having the mixer remember the identity associated=20 > >> > >>with each=20 > >> > >>> > connection. > >>> > >>>This would still not work, since there isn't a vehicle in=20 > >> > >>the protocol to transport this "asserted-identity" to the=20 > >>recipient endpoints. > >> > >>>=20 > >>> > The mixer could also insist that all content be wrapped in=20 > >>> > message/cpim=20 > >>> > using our extension to the SDP format list negotiation. > >>> > >>>Which is fine, if all MSRP endpoints are required to=20 > >> > >>support it. Currently they aren't which potentially leaves a=20 > >>lot of MSRP clients incapable of participating in message=20 > >>session conferences. > >> > >>I am not opposed to requiring support for this. In=20 > >>retrospect, I think=20 > >>we intended to do that and it just didn't make it in. > >> > >> > >>>Regards, > >>>Aki > >>> > >>> > Aki Niemi wrote: > >>> >=20 > >>> > > Hi All, > >>> > >=20 > >>> > > Since MSGFMT is no longer mandated (or is but only for=20 > >>> > CPIM gateways),=20 > >>> > > how would a participant know where a message is coming=20 > >> > >>from in a=20 > >> > >>> > > multiparty message session? > >>> > >=20 > >>> > > Also, when using MSRP in a conferencing system, the lack=20 > >>> > of To/From=20 > >>> > > prevents sending private messages efficiently within a=20 > >> > >>multiparty=20 > >> > >>> > > session using an MSRP mixer as a "router" for them. > >>> > >=20 > >>> > > So my question is this: what is the extensibility model=20 > >>> > for MSRP? For=20 > >>> > > example, would it be possible to later on add this multiparty=20 > >>> > > functionality as an extension, or would it be wise to=20 > >> > >>think ahead=20 > >> > >>> > > already now? > >>> > >=20 > >>> > > The draft includes some extensibility, e.g., for=20 > >> > >>authentication=20 > >> > >>> > > algorithms, but I didn't immediately find much about=20 > >>> > adding methods and=20 > >>> > > headers, and what to do with unknown headers. > >>> > >=20 > >>> > > Regards, > >>> > > Aki > >>> > >=20 > >>> > >=20 > >>> > > _______________________________________________ > >>> > > Simple mailing list > >>> > > Simple@ietf.org > >>> > > https://www1.ietf.org/mailman/listinfo/simple > >>> >=20 > >>> >=20 > >>> >=20 > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 20 14:30:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06947 for ; Mon, 20 Oct 2003 14:30:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABen8-0003FR-IF for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KIU6En012479 for simple-archive@odin.ietf.org; Mon, 20 Oct 2003 14:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABen8-0003FC-ET for simple-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06873; Mon, 20 Oct 2003 14:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABen5-0003CN-00; Mon, 20 Oct 2003 14:30:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABen4-0003CK-00; Mon, 20 Oct 2003 14:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABen3-0003BY-TK; Mon, 20 Oct 2003 14:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABemi-00030u-On for simple@optimus.ietf.org; Mon, 20 Oct 2003 14:29:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06858 for ; Mon, 20 Oct 2003 14:29:30 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABemg-0003Bz-00 for simple@ietf.org; Mon, 20 Oct 2003 14:29:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABemf-0003Bw-00 for simple@ietf.org; Mon, 20 Oct 2003 14:29:37 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KITad09144 for ; Mon, 20 Oct 2003 21:29:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Oct 2003 21:29:35 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 21:29:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on MSRP - multiparty message session support X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972C4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on MSRP - multiparty message session support Thread-Index: AcOXN5jfiGedKPJTSTKNfVp3XbAL7QAAFUgw To: Cc: , X-OriginalArrivalTime: 20 Oct 2003 18:29:35.0801 (UTC) FILETIME=[1D0F4A90:01C39738] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Oct 2003 21:29:35 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes, just support. If a conference server wants message/cpim, it = indicates so in the offer or answer (dial out and dial in cases) /Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, October 20, 2003 9:25 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Niemi Aki (NMP/Helsinki); simple@ietf.org > Subject: Re: [Simple] Comments on MSRP - multiparty message session > support >=20 >=20 > Just to be sure that we are clear on this, I agree that we should=20 > mandate _support_. _Use_ is still up to the endpoints to=20 > negotiated. I=20 > think this accomplishes what we need, without encumbering simple=20 > point-to-point sessions with the extra overhead. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > This is very much inline with Pekka's suggestion and I like it. > >=20 > > I vote for mandating message/cpim. Of course, we still need=20 > to signal what mime-types an endpoint supports, using SDP. > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: Monday, October 20, 2003 4:31 PM > >>To: Niemi Aki (NMP/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] Comments on MSRP - multiparty message session > >>support > >> > >> > >>aki.niemi@nokia.com wrote: > >> > >> > >>> > -----Original Message----- > >>> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> > Sent: 17 October, 2003 20:36 > >>> > To: Niemi Aki (NMP/Helsinki) > >>> > Cc: simple@ietf.org > >>> > Subject: Re: [Simple] Comments on MSRP - multiparty=20 > >> > >>message session > >> > >>> > support > >>> >=20 > >>> >=20 > >>> > We talked about how this could be done in a couple of ways.=20 > >>> > One was by=20 > >>> > simply having the mixer remember the identity associated=20 > >> > >>with each=20 > >> > >>> > connection. > >>> > >>>This would still not work, since there isn't a vehicle in=20 > >> > >>the protocol to transport this "asserted-identity" to the=20 > >>recipient endpoints. > >> > >>>=20 > >>> > The mixer could also insist that all content be wrapped in=20 > >>> > message/cpim=20 > >>> > using our extension to the SDP format list negotiation. > >>> > >>>Which is fine, if all MSRP endpoints are required to=20 > >> > >>support it. Currently they aren't which potentially leaves a=20 > >>lot of MSRP clients incapable of participating in message=20 > >>session conferences. > >> > >>I am not opposed to requiring support for this. In=20 > >>retrospect, I think=20 > >>we intended to do that and it just didn't make it in. > >> > >> > >>>Regards, > >>>Aki > >>> > >>> > Aki Niemi wrote: > >>> >=20 > >>> > > Hi All, > >>> > >=20 > >>> > > Since MSGFMT is no longer mandated (or is but only for=20 > >>> > CPIM gateways),=20 > >>> > > how would a participant know where a message is coming=20 > >> > >>from in a=20 > >> > >>> > > multiparty message session? > >>> > >=20 > >>> > > Also, when using MSRP in a conferencing system, the lack=20 > >>> > of To/From=20 > >>> > > prevents sending private messages efficiently within a=20 > >> > >>multiparty=20 > >> > >>> > > session using an MSRP mixer as a "router" for them. > >>> > >=20 > >>> > > So my question is this: what is the extensibility model=20 > >>> > for MSRP? For=20 > >>> > > example, would it be possible to later on add this multiparty=20 > >>> > > functionality as an extension, or would it be wise to=20 > >> > >>think ahead=20 > >> > >>> > > already now? > >>> > >=20 > >>> > > The draft includes some extensibility, e.g., for=20 > >> > >>authentication=20 > >> > >>> > > algorithms, but I didn't immediately find much about=20 > >>> > adding methods and=20 > >>> > > headers, and what to do with unknown headers. > >>> > >=20 > >>> > > Regards, > >>> > > Aki > >>> > >=20 > >>> > >=20 > >>> > > _______________________________________________ > >>> > > Simple mailing list > >>> > > Simple@ietf.org > >>> > > https://www1.ietf.org/mailman/listinfo/simple > >>> >=20 > >>> >=20 > >>> >=20 > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 01:10:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23578; Tue, 21 Oct 2003 01:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABonS-0007Gw-00; Tue, 21 Oct 2003 01:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABonS-0007Gt-00; Tue, 21 Oct 2003 01:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABonO-0003xS-54; Tue, 21 Oct 2003 01:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABonH-0003ve-Ea for simple@optimus.ietf.org; Tue, 21 Oct 2003 01:10:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23546 for ; Tue, 21 Oct 2003 01:10:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABonE-0007GR-00 for simple@ietf.org; Tue, 21 Oct 2003 01:10:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ABonD-0007G9-00 for simple@ietf.org; Tue, 21 Oct 2003 01:10:51 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9L5APca002943; Tue, 21 Oct 2003 01:10:25 -0400 (EDT) Message-ID: <3F94BFBC.7010405@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, hardie@qualcomm.com, simple@ietf.org Subject: Re: [Simple] What can you do with a list? References: <2038BCC78B1AD641891A0D1AE133DBB701947C51@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701947C51@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 01:10:20 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I think (2) is needed. If you would like to pursue option 1 for > now, but delay 2, then I suggest removing any text referring to the > list as a presence list. > > There is nothing in the draft that tells what package is the list > "subscrible" for. It is assumed that it is the presence event > package. If you want to extract those service specifics, again, I > suggest not referring to presence in this draft. > > We could then would write a draft for "subscribe to presence", > "messagable", etc. I think it would be OK to make the list descriptions generic, and also include in the draft the information on how to subscribe to presence. Anyway, it seems there is consensus to do (1), and to pursue (2) separately. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 01:11:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23602 for ; Tue, 21 Oct 2003 01:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABonW-0003zg-98 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 01:11:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L5BAtq015348 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 01:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABonW-0003zT-4x for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 01:11:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23578; Tue, 21 Oct 2003 01:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABonS-0007Gw-00; Tue, 21 Oct 2003 01:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABonS-0007Gt-00; Tue, 21 Oct 2003 01:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABonO-0003xS-54; Tue, 21 Oct 2003 01:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABonH-0003ve-Ea for simple@optimus.ietf.org; Tue, 21 Oct 2003 01:10:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23546 for ; Tue, 21 Oct 2003 01:10:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABonE-0007GR-00 for simple@ietf.org; Tue, 21 Oct 2003 01:10:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ABonD-0007G9-00 for simple@ietf.org; Tue, 21 Oct 2003 01:10:51 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9L5APca002943; Tue, 21 Oct 2003 01:10:25 -0400 (EDT) Message-ID: <3F94BFBC.7010405@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, hardie@qualcomm.com, simple@ietf.org Subject: Re: [Simple] What can you do with a list? References: <2038BCC78B1AD641891A0D1AE133DBB701947C51@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701947C51@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 01:10:20 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I think (2) is needed. If you would like to pursue option 1 for > now, but delay 2, then I suggest removing any text referring to the > list as a presence list. > > There is nothing in the draft that tells what package is the list > "subscrible" for. It is assumed that it is the presence event > package. If you want to extract those service specifics, again, I > suggest not referring to presence in this draft. > > We could then would write a draft for "subscribe to presence", > "messagable", etc. I think it would be OK to make the list descriptions generic, and also include in the draft the information on how to subscribe to presence. Anyway, it seems there is consensus to do (1), and to pursue (2) separately. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 03:44:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09091; Tue, 21 Oct 2003 03:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrBZ-0000fV-00; Tue, 21 Oct 2003 03:44:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrBY-0000fS-00; Tue, 21 Oct 2003 03:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrBR-0002rm-FU; Tue, 21 Oct 2003 03:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrAs-0002m4-SO for simple@optimus.ietf.org; Tue, 21 Oct 2003 03:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09076 for ; Tue, 21 Oct 2003 03:43:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrAq-0000el-00 for simple@ietf.org; Tue, 21 Oct 2003 03:43:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABrAp-0000ei-00 for simple@ietf.org; Tue, 21 Oct 2003 03:43:23 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L7hNd23275 for ; Tue, 21 Oct 2003 10:43:23 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 10:43:23 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 10:43:22 +0300 Message-ID: <3F94E39B.4050203@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext hisham.khartabil@nokia.com" CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 07:43:22.0896 (UTC) FILETIME=[01054100:01C397A7] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 10:43:23 +0300 Content-Transfer-Encoding: 7bit On 20.10.2003 20:29, ext hisham.khartabil@nokia.com: > >> -----Original Message----- From: ext Ben Campbell >> [mailto:bcampbell@dynamicsoft.com] Sent: Friday, October 17, 2003 >> 8:44 PM To: Niemi Aki (NMP/Helsinki) Cc: simple@ietf.org Subject: >> Re: [Simple] MSRP comments - request/response handling and retrying >> >> >> >> Based on recent discussions, I think we may need to rethink this. >> The point to resending was _not_ to build a reliability mechanism >> on top of TCP. We really wanted a mechanism to simply warn the user >> if we could not be sure the opposite endpoint had actually >> processed the message. I think we should either remove the text >> encouraging re-submission, or change it to re-use the same TR-ID, >> and add text to describe what the peer should do if it sees >> duplicate TR-IDs. > > > I would hate to resend a 5gb message. I think there should be a timer > for the response, without retransmissions. If the timer fires, then > you have to assume that something went wrong in delivering the > message. Retransmission won't help. I agree that retransmissions should go. I can't think of a scenario where a message would be lost over reliable transports, so that retransmitting it would ever help. But just having the request time out should probably not immediately result in session tear down. The MSRP client should at least wait as long as the downstream connection is active. The missing response could always be pipelined in that stream behind some other request/response. Regards, Aki >> >> Having a response delayed by a long request in the recipricol >> direction is a problem I don't think we have considered. I welcome >> input as to whether we think this is a real issue, and if so, how >> to deal with it. > > I thought we agreed that large messages should be sent using a > separate session. Or we change that decision? If not, I cannot recall > if there was a threshold that classifies as message as large. > > /Hisham > >> >> Aki Niemi wrote: >> >>> Hi, >>> >>> In the draft, if a SEND times out, the MSRP client is >> supposed to handle >>> this as if a 5xx was received. I.e., it will resend the >> message a few >>> times and then quit the session. In case the other endpoint >> is in the >>> midst of sending a large message, a response may take >> longer than the >>> request time out value. This will result in a number of duplicate >>> messages received. There should be a better way to handle this. >>> Why resend in the first place, especially if the connection is >>> active? >>> >>> Also, what is the motivation for making retransmissions >> with a different >>> TR-ID? Doesn't this go agains the idea of retrying the request? >>> >>> Regards, Aki >>> >>> >>> _______________________________________________ Simple mailing >>> list Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ Simple mailing list >> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 03:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09115 for ; Tue, 21 Oct 2003 03:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrBc-0002u0-FU for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 03:44:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L7iCMK011140 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 03:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrBc-0002tb-6G for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 03:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09091; Tue, 21 Oct 2003 03:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrBZ-0000fV-00; Tue, 21 Oct 2003 03:44:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrBY-0000fS-00; Tue, 21 Oct 2003 03:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrBR-0002rm-FU; Tue, 21 Oct 2003 03:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrAs-0002m4-SO for simple@optimus.ietf.org; Tue, 21 Oct 2003 03:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09076 for ; Tue, 21 Oct 2003 03:43:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrAq-0000el-00 for simple@ietf.org; Tue, 21 Oct 2003 03:43:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABrAp-0000ei-00 for simple@ietf.org; Tue, 21 Oct 2003 03:43:23 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L7hNd23275 for ; Tue, 21 Oct 2003 10:43:23 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 10:43:23 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 10:43:22 +0300 Message-ID: <3F94E39B.4050203@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext hisham.khartabil@nokia.com" CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 07:43:22.0896 (UTC) FILETIME=[01054100:01C397A7] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 10:43:23 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 20.10.2003 20:29, ext hisham.khartabil@nokia.com: > >> -----Original Message----- From: ext Ben Campbell >> [mailto:bcampbell@dynamicsoft.com] Sent: Friday, October 17, 2003 >> 8:44 PM To: Niemi Aki (NMP/Helsinki) Cc: simple@ietf.org Subject: >> Re: [Simple] MSRP comments - request/response handling and retrying >> >> >> >> Based on recent discussions, I think we may need to rethink this. >> The point to resending was _not_ to build a reliability mechanism >> on top of TCP. We really wanted a mechanism to simply warn the user >> if we could not be sure the opposite endpoint had actually >> processed the message. I think we should either remove the text >> encouraging re-submission, or change it to re-use the same TR-ID, >> and add text to describe what the peer should do if it sees >> duplicate TR-IDs. > > > I would hate to resend a 5gb message. I think there should be a timer > for the response, without retransmissions. If the timer fires, then > you have to assume that something went wrong in delivering the > message. Retransmission won't help. I agree that retransmissions should go. I can't think of a scenario where a message would be lost over reliable transports, so that retransmitting it would ever help. But just having the request time out should probably not immediately result in session tear down. The MSRP client should at least wait as long as the downstream connection is active. The missing response could always be pipelined in that stream behind some other request/response. Regards, Aki >> >> Having a response delayed by a long request in the recipricol >> direction is a problem I don't think we have considered. I welcome >> input as to whether we think this is a real issue, and if so, how >> to deal with it. > > I thought we agreed that large messages should be sent using a > separate session. Or we change that decision? If not, I cannot recall > if there was a threshold that classifies as message as large. > > /Hisham > >> >> Aki Niemi wrote: >> >>> Hi, >>> >>> In the draft, if a SEND times out, the MSRP client is >> supposed to handle >>> this as if a 5xx was received. I.e., it will resend the >> message a few >>> times and then quit the session. In case the other endpoint >> is in the >>> midst of sending a large message, a response may take >> longer than the >>> request time out value. This will result in a number of duplicate >>> messages received. There should be a better way to handle this. >>> Why resend in the first place, especially if the connection is >>> active? >>> >>> Also, what is the motivation for making retransmissions >> with a different >>> TR-ID? Doesn't this go agains the idea of retrying the request? >>> >>> Regards, Aki >>> >>> >>> _______________________________________________ Simple mailing >>> list Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ Simple mailing list >> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 03:55:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09275; Tue, 21 Oct 2003 03:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrMD-0000iz-00; Tue, 21 Oct 2003 03:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrMC-0000iw-00; Tue, 21 Oct 2003 03:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrM5-0006BB-SA; Tue, 21 Oct 2003 03:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrLW-0005zL-0d for simple@optimus.ietf.org; Tue, 21 Oct 2003 03:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09254 for ; Tue, 21 Oct 2003 03:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrLT-0000iZ-00 for simple@ietf.org; Tue, 21 Oct 2003 03:54:23 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABrLS-0000iW-00 for simple@ietf.org; Tue, 21 Oct 2003 03:54:22 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L7sLX24694 for ; Tue, 21 Oct 2003 10:54:21 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 10:54:20 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 10:54:05 +0300 Message-ID: <3F94E61D.3010406@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat CC: Ben Campbell , "Khartabil Hisham (NMP-MSW/Helsinki)" , simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> <3F941D61.2090800@dynamicsoft.com> <3F942533.1000303@cisco.com> In-Reply-To: <3F942533.1000303@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 07:54:05.0426 (UTC) FILETIME=[7FFF8D20:01C397A8] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 10:54:05 +0300 Content-Transfer-Encoding: 7bit On 20.10.2003 21:10, ext Paul Kyzivat: > > Ben Campbell wrote: >> >>>> Having a response delayed by a long request in the recipricol >>>> direction is a problem I don't think we have considered. I welcome >>>> input as to whether we think this is a real issue, and if so, how to >>>> deal with it. >>> >>> I thought we agreed that large messages should be sent using a >>> separate session. Or we change that decision? If not, I cannot recall >>> if there was a threshold that classifies as message as large. >> >> You are correct, we have text encouraging this behavior. Since you >> reminded me of this, and no one else jumped in to say that this is a big >> problem, I am going to assume for now that it is not. If anyone feels >> otherwise, please jump in asap. > > I'm not sure if that solves the problem. It just moves it to the > separate session. I guess it goes away if we assume that each and every > large message should get its very own session, but that doesn't sound > like a wonderful solution. > > Perhaps a session intended for large messages should not be used to > initiate messages (large or small) in the reverse direction. So, I can > create a special stream to send files to you, and pour several files > thru it. But if you have files to send to me then you should set up a > separate stream. > > That of course punts the question of how the two ends agree on the > intended use of a stream. Just because I establish the stream with the > intent of sending large messages to you, that doesn't mean you know > that. If you don't you might start sending small messages to me over it. > > Maybe we need some sort of purpose attribute, or a maximum size > attribute, that can be specified/negotiated during session > establishment. One answer might be to use a=sendonly to indicate a > stream that should only be used in one direction. On such a stream only > responses would be permitted in the reverse direction. This sounds like a good solution. There is still one thing though, what is considered a large message? I don't believe we can define a threshold, so a sendrecv stream could still end up carrying a sizeable message, and the problem would remain. I think the way round this problem could be that a) we get rid of retransmissions, and b) base the request timeout on both connection activity and a timer. If a request was sent, and the connection stays inactive for the timer to fire, only then would the client assume the session has failed, and proceed with tear down. Regards, Aki > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 03:55:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09296 for ; Tue, 21 Oct 2003 03:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrMG-0006Hc-V9 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 03:55:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L7tClT024020 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 03:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrMG-0006FG-9p for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 03:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09275; Tue, 21 Oct 2003 03:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrMD-0000iz-00; Tue, 21 Oct 2003 03:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrMC-0000iw-00; Tue, 21 Oct 2003 03:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrM5-0006BB-SA; Tue, 21 Oct 2003 03:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrLW-0005zL-0d for simple@optimus.ietf.org; Tue, 21 Oct 2003 03:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09254 for ; Tue, 21 Oct 2003 03:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrLT-0000iZ-00 for simple@ietf.org; Tue, 21 Oct 2003 03:54:23 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABrLS-0000iW-00 for simple@ietf.org; Tue, 21 Oct 2003 03:54:22 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L7sLX24694 for ; Tue, 21 Oct 2003 10:54:21 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 10:54:20 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 10:54:05 +0300 Message-ID: <3F94E61D.3010406@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat CC: Ben Campbell , "Khartabil Hisham (NMP-MSW/Helsinki)" , simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> <3F941D61.2090800@dynamicsoft.com> <3F942533.1000303@cisco.com> In-Reply-To: <3F942533.1000303@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 07:54:05.0426 (UTC) FILETIME=[7FFF8D20:01C397A8] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 10:54:05 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 20.10.2003 21:10, ext Paul Kyzivat: > > Ben Campbell wrote: >> >>>> Having a response delayed by a long request in the recipricol >>>> direction is a problem I don't think we have considered. I welcome >>>> input as to whether we think this is a real issue, and if so, how to >>>> deal with it. >>> >>> I thought we agreed that large messages should be sent using a >>> separate session. Or we change that decision? If not, I cannot recall >>> if there was a threshold that classifies as message as large. >> >> You are correct, we have text encouraging this behavior. Since you >> reminded me of this, and no one else jumped in to say that this is a big >> problem, I am going to assume for now that it is not. If anyone feels >> otherwise, please jump in asap. > > I'm not sure if that solves the problem. It just moves it to the > separate session. I guess it goes away if we assume that each and every > large message should get its very own session, but that doesn't sound > like a wonderful solution. > > Perhaps a session intended for large messages should not be used to > initiate messages (large or small) in the reverse direction. So, I can > create a special stream to send files to you, and pour several files > thru it. But if you have files to send to me then you should set up a > separate stream. > > That of course punts the question of how the two ends agree on the > intended use of a stream. Just because I establish the stream with the > intent of sending large messages to you, that doesn't mean you know > that. If you don't you might start sending small messages to me over it. > > Maybe we need some sort of purpose attribute, or a maximum size > attribute, that can be specified/negotiated during session > establishment. One answer might be to use a=sendonly to indicate a > stream that should only be used in one direction. On such a stream only > responses would be permitted in the reverse direction. This sounds like a good solution. There is still one thing though, what is considered a large message? I don't believe we can define a threshold, so a sendrecv stream could still end up carrying a sizeable message, and the problem would remain. I think the way round this problem could be that a) we get rid of retransmissions, and b) base the request timeout on both connection activity and a timer. If a request was sent, and the connection stays inactive for the timer to fire, only then would the client assume the session has failed, and proceed with tear down. Regards, Aki > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 04:03:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09471; Tue, 21 Oct 2003 04:03:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrUp-0000mG-00; Tue, 21 Oct 2003 04:04:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrUo-0000mD-00; Tue, 21 Oct 2003 04:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrUn-0008Rn-T3; Tue, 21 Oct 2003 04:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrTn-0008Dg-VQ for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:03:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09458 for ; Tue, 21 Oct 2003 04:02:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrTl-0000lm-00 for simple@ietf.org; Tue, 21 Oct 2003 04:02:57 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABrTk-0000lj-00 for simple@ietf.org; Tue, 21 Oct 2003 04:02:56 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L82ud15636 for ; Tue, 21 Oct 2003 11:02:56 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 11:02:54 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:01:02 +0300 Message-ID: <3F94E7BE.3020609@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: RE: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 08:01:02.0529 (UTC) FILETIME=[789C6B10:01C397A9] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:01:02 +0300 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On > Behalf Of > ext Ben Campbell > Sent: 20 October, 2003 20:35 > To: Niemi Aki (NMP/Helsinki) > Cc: pkyzivat@cisco.com; rsparks@dynamicsoft.com; simple@ietf.org > Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for > group opinion (was MSRP: Administrative shutdown of relays)) > > > aki.niemi@nokia.com wrote: > > [...] > > > > Sure, it says the connection should be torn down. It > does not say > > > anything at all about whether a client should automatically > > > attempt to > > > create a new session or not. I don't think we should specify > > > that sort > > > of behavior one way or another. It does not seem to affect > > > interoperability in any way. > > > > OK, then I misinterpreted you before. I thought by > auto-resume, the MSRP client would try to resume the *MSRP* > session, meaning something like establish a new TCP > connection, do a VISIT, etc. Maybe some clarification to the > term "session" is needed here? > > > > One thing related to this though, in case an MSRP peer > wants to establish a new MSRP connection for e.g. > filetransfer, should it assume the "direction" properties of > the existing MSRP session, or should the endpoints do a full > handshake on it? > > > > My proposal (which would require some text in MSRP) would > be that the directional proerties of the original MSRP > connection are reused. I would expect the circumstances in > the network to remain constant, so that the direction of the > new MSRP session would likely turn out the same as the original one. > > > > Why do we need to special case this? I don't think the added > efficiency > is enough to justify the special case. Well, because it *is* a special case. I think it's quite reasonable to expect that an endpoint having said "both" the first time around, failed to be the host, and consequently forced to visit, would not reinvite using direction:both, but direction:active instead. Having said that though, this is possible to do as the text stands now. So no additional specification needed, except some informative note, if anything. Cheers, Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 04:04:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09495 for ; Tue, 21 Oct 2003 04:04:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrUt-0008Tb-Dx for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:04:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L847WG032577 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrUs-0008Sw-Gq for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 04:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09471; Tue, 21 Oct 2003 04:03:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrUp-0000mG-00; Tue, 21 Oct 2003 04:04:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrUo-0000mD-00; Tue, 21 Oct 2003 04:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrUn-0008Rn-T3; Tue, 21 Oct 2003 04:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrTn-0008Dg-VQ for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:03:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09458 for ; Tue, 21 Oct 2003 04:02:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrTl-0000lm-00 for simple@ietf.org; Tue, 21 Oct 2003 04:02:57 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABrTk-0000lj-00 for simple@ietf.org; Tue, 21 Oct 2003 04:02:56 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L82ud15636 for ; Tue, 21 Oct 2003 11:02:56 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 11:02:54 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:01:02 +0300 Message-ID: <3F94E7BE.3020609@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: RE: MSRP: resuming sessions (was Re: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 08:01:02.0529 (UTC) FILETIME=[789C6B10:01C397A9] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:01:02 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On > Behalf Of > ext Ben Campbell > Sent: 20 October, 2003 20:35 > To: Niemi Aki (NMP/Helsinki) > Cc: pkyzivat@cisco.com; rsparks@dynamicsoft.com; simple@ietf.org > Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for > group opinion (was MSRP: Administrative shutdown of relays)) > > > aki.niemi@nokia.com wrote: > > [...] > > > > Sure, it says the connection should be torn down. It > does not say > > > anything at all about whether a client should automatically > > > attempt to > > > create a new session or not. I don't think we should specify > > > that sort > > > of behavior one way or another. It does not seem to affect > > > interoperability in any way. > > > > OK, then I misinterpreted you before. I thought by > auto-resume, the MSRP client would try to resume the *MSRP* > session, meaning something like establish a new TCP > connection, do a VISIT, etc. Maybe some clarification to the > term "session" is needed here? > > > > One thing related to this though, in case an MSRP peer > wants to establish a new MSRP connection for e.g. > filetransfer, should it assume the "direction" properties of > the existing MSRP session, or should the endpoints do a full > handshake on it? > > > > My proposal (which would require some text in MSRP) would > be that the directional proerties of the original MSRP > connection are reused. I would expect the circumstances in > the network to remain constant, so that the direction of the > new MSRP session would likely turn out the same as the original one. > > > > Why do we need to special case this? I don't think the added > efficiency > is enough to justify the special case. Well, because it *is* a special case. I think it's quite reasonable to expect that an endpoint having said "both" the first time around, failed to be the host, and consequently forced to visit, would not reinvite using direction:both, but direction:active instead. Having said that though, this is possible to do as the text stands now. So no additional specification needed, except some informative note, if anything. Cheers, Aki > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 04:18:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09866; Tue, 21 Oct 2003 04:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrjM-0000uu-00; Tue, 21 Oct 2003 04:19:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrjM-0000ur-00; Tue, 21 Oct 2003 04:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrjJ-0004ZD-Eq; Tue, 21 Oct 2003 04:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABriS-0004Og-7i for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09851 for ; Tue, 21 Oct 2003 04:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABriP-0000uW-00 for simple@ietf.org; Tue, 21 Oct 2003 04:18:05 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ABriO-0000uG-00 for simple@ietf.org; Tue, 21 Oct 2003 04:18:04 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9L8HTO8002751; Tue, 21 Oct 2003 03:17:29 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100 [153.88.94.27]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VDTCYR; Tue, 21 Oct 2003 03:16:40 -0500 Message-ID: <3F94EB93.20609@ericsson.com> X-Sybari-Trust: d203ca70 406a040f c001c63b 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, hardie@qualcomm.com, simple@ietf.org Subject: Re: [Simple] What can you do with a list? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:17:23 +0300 Content-Transfer-Encoding: 7bit Folks, > I'm also happy to go for option (1) now, and leave (2) for an extension. Yes, that would be OK. Regarding (2), we can agree on the requirements in SIPPING (they are only a few of them) and have an ad-hoc (bar BOF) in Minneapolis about potential solutions. Reporting to the initiator is one of the issues we need to talk about. I agree that the more important cases are MESSAGE and INVITE... it is clear that the INVITE case could be addressed with CPCP as well, but I see value in having a simpler way of doing that in addition to CPCP. Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 04:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09904 for ; Tue, 21 Oct 2003 04:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrjQ-0004eW-Gd for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:19:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L8J8b8017883 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrjQ-0004e1-3N for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 04:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09866; Tue, 21 Oct 2003 04:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrjM-0000uu-00; Tue, 21 Oct 2003 04:19:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrjM-0000ur-00; Tue, 21 Oct 2003 04:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrjJ-0004ZD-Eq; Tue, 21 Oct 2003 04:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABriS-0004Og-7i for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09851 for ; Tue, 21 Oct 2003 04:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABriP-0000uW-00 for simple@ietf.org; Tue, 21 Oct 2003 04:18:05 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ABriO-0000uG-00 for simple@ietf.org; Tue, 21 Oct 2003 04:18:04 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9L8HTO8002751; Tue, 21 Oct 2003 03:17:29 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100 [153.88.94.27]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S8VDTCYR; Tue, 21 Oct 2003 03:16:40 -0500 Message-ID: <3F94EB93.20609@ericsson.com> X-Sybari-Trust: d203ca70 406a040f c001c63b 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, hardie@qualcomm.com, simple@ietf.org Subject: Re: [Simple] What can you do with a list? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:17:23 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, > I'm also happy to go for option (1) now, and leave (2) for an extension. Yes, that would be OK. Regarding (2), we can agree on the requirements in SIPPING (they are only a few of them) and have an ad-hoc (bar BOF) in Minneapolis about potential solutions. Reporting to the initiator is one of the issues we need to talk about. I agree that the more important cases are MESSAGE and INVITE... it is clear that the INVITE case could be addressed with CPCP as well, but I see value in having a simpler way of doing that in addition to CPCP. Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 04:25:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10049; Tue, 21 Oct 2003 04:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrq7-0000yW-00; Tue, 21 Oct 2003 04:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrq7-0000yT-00; Tue, 21 Oct 2003 04:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrq5-0006p7-A1; Tue, 21 Oct 2003 04:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrpi-0006fb-Vj for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10037 for ; Tue, 21 Oct 2003 04:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrpf-0000y6-00 for simple@ietf.org; Tue, 21 Oct 2003 04:25:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABrpf-0000y3-00 for simple@ietf.org; Tue, 21 Oct 2003 04:25:35 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L8PZX04586 for ; Tue, 21 Oct 2003 11:25:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Oct 2003 11:25:35 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:25:35 +0300 Message-ID: <3F94ED7F.5050700@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 08:25:35.0438 (UTC) FILETIME=[E6887EE0:01C397AC] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP comments - security Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:25:35 +0300 Content-Transfer-Encoding: 7bit Hi, A couple more things came to mind about MSRP security. There are multiple authentication mechanisms available (digest, TLS authentication), as well as potentially many digest algorithms available (SHA1, plus extensibility). First of all, the security considerations should probably say something about authenticating with multiple mechanisms, and the vulnerabilities this might introduce. For example, TLS could be used to authenticate the server, and then digest could be used to authenticate the client after the TLS tunnel is established. There is potential for a MITM attack, if these same digest credentials are ever used without the TLS tunnel [1]. Secondly, the digest mechanism has extensibility for other digest algorithms, yet the SChal "algorithm" parameter is single valued. This is a problem, since the client has no way to indicate the server challenge contained an algorithm it does not support. Hence there needs to be a way to negotiate the used algorithm, e.g., by the server challenging with a list, and the client then picking one from that list. Furthermore, if negotiation of the used algorithm isn't secure, there is a possibility for a bidding down attack. So, my proposal is to modify the SChal so that the algorithm field is multi-valued, and this field is also included in the request-digest. The algorithm field in the CAuth then again needs to be single-valued, to indicate which algorithm was chosen by the client. Regards, Aki [1] http://eprint.iacr.org/2002/163/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 04:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10075 for ; Tue, 21 Oct 2003 04:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrqB-0006uH-M8 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L8Q7si026543 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrqB-0006u2-9Y for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 04:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10049; Tue, 21 Oct 2003 04:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrq7-0000yW-00; Tue, 21 Oct 2003 04:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrq7-0000yT-00; Tue, 21 Oct 2003 04:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrq5-0006p7-A1; Tue, 21 Oct 2003 04:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrpi-0006fb-Vj for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10037 for ; Tue, 21 Oct 2003 04:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrpf-0000y6-00 for simple@ietf.org; Tue, 21 Oct 2003 04:25:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABrpf-0000y3-00 for simple@ietf.org; Tue, 21 Oct 2003 04:25:35 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L8PZX04586 for ; Tue, 21 Oct 2003 11:25:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Oct 2003 11:25:35 +0300 Received: from nokia.com ([172.21.11.74]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:25:35 +0300 Message-ID: <3F94ED7F.5050700@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2003 08:25:35.0438 (UTC) FILETIME=[E6887EE0:01C397AC] Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP comments - security Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:25:35 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, A couple more things came to mind about MSRP security. There are multiple authentication mechanisms available (digest, TLS authentication), as well as potentially many digest algorithms available (SHA1, plus extensibility). First of all, the security considerations should probably say something about authenticating with multiple mechanisms, and the vulnerabilities this might introduce. For example, TLS could be used to authenticate the server, and then digest could be used to authenticate the client after the TLS tunnel is established. There is potential for a MITM attack, if these same digest credentials are ever used without the TLS tunnel [1]. Secondly, the digest mechanism has extensibility for other digest algorithms, yet the SChal "algorithm" parameter is single valued. This is a problem, since the client has no way to indicate the server challenge contained an algorithm it does not support. Hence there needs to be a way to negotiate the used algorithm, e.g., by the server challenging with a list, and the client then picking one from that list. Furthermore, if negotiation of the used algorithm isn't secure, there is a possibility for a bidding down attack. So, my proposal is to modify the SChal so that the algorithm field is multi-valued, and this field is also included in the request-digest. The algorithm field in the CAuth then again needs to be single-valued, to indicate which algorithm was chosen by the client. Regards, Aki [1] http://eprint.iacr.org/2002/163/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 04:27:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10110; Tue, 21 Oct 2003 04:27:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrs1-0000za-00; Tue, 21 Oct 2003 04:28:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrs1-0000zX-00; Tue, 21 Oct 2003 04:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrs2-0007Df-4B; Tue, 21 Oct 2003 04:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrrO-00075f-1F for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10104 for ; Tue, 21 Oct 2003 04:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrrK-0000zI-00 for simple@ietf.org; Tue, 21 Oct 2003 04:27:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABrrK-0000zF-00 for simple@ietf.org; Tue, 21 Oct 2003 04:27:18 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L8RIX06654 for ; Tue, 21 Oct 2003 11:27:18 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 11:27:18 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:27:17 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA10826; Tue, 21 Oct 2003 11:27:18 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9L8RCqs003875; Tue, 21 Oct 2003 11:27:12 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9L8RBLl003874; Tue, 21 Oct 2003 11:27:11 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Aki Niemi Cc: ext Paul Kyzivat , Ben Campbell , "Khartabil Hisham (NMP-MSW/Helsinki)" , simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F94E61D.3010406@nokia.com> (Aki Niemi's message of "Tue, 21 Oct 2003 10:54:05 +0300") References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> <3F941D61.2090800@dynamicsoft.com> <3F942533.1000303@cisco.com> <3F94E61D.3010406@nokia.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 21 Oct 2003 08:27:17.0746 (UTC) FILETIME=[23837520:01C397AD] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:27:11 +0300 Hi,, Aki Niemi writes: >I think the way round this problem could be that a) we get rid of >retransmissions, and b) base the request timeout on both connection activity >and a timer. If a request was sent, and the connection stays inactive for >the timer to fire, only then would the client assume the session has failed, >and proceed with tear down. I think we have a problem here because of relays. Even if you have sent your message completely and the relay has received it via TCP, it does not mean that the whole message has been relayed, even if we assume cut-through relaying. Two relays make it worse: there is 3 TCP send buffers and receive buffer between sender and recipient. If we add timer, we also need some kind of keepalive messages that can be sent while receiving a large message. 100 Continue? Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 04:28:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10149 for ; Tue, 21 Oct 2003 04:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrs5-0007Hw-8U for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L8S5PT028010 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 04:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrs5-0007Hh-4n for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 04:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10110; Tue, 21 Oct 2003 04:27:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrs1-0000za-00; Tue, 21 Oct 2003 04:28:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrs1-0000zX-00; Tue, 21 Oct 2003 04:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrs2-0007Df-4B; Tue, 21 Oct 2003 04:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrrO-00075f-1F for simple@optimus.ietf.org; Tue, 21 Oct 2003 04:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10104 for ; Tue, 21 Oct 2003 04:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrrK-0000zI-00 for simple@ietf.org; Tue, 21 Oct 2003 04:27:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABrrK-0000zF-00 for simple@ietf.org; Tue, 21 Oct 2003 04:27:18 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L8RIX06654 for ; Tue, 21 Oct 2003 11:27:18 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 11:27:18 +0300 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:27:17 +0300 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA10826; Tue, 21 Oct 2003 11:27:18 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9L8RCqs003875; Tue, 21 Oct 2003 11:27:12 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h9L8RBLl003874; Tue, 21 Oct 2003 11:27:11 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Aki Niemi Cc: ext Paul Kyzivat , Ben Campbell , "Khartabil Hisham (NMP-MSW/Helsinki)" , simple@ietf.org Subject: Re: [Simple] MSRP comments - request/response handling and retrying X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F94E61D.3010406@nokia.com> (Aki Niemi's message of "Tue, 21 Oct 2003 10:54:05 +0300") References: <2038BCC78B1AD641891A0D1AE133DBB701947C50@esebe019.ntc.nokia.com> <3F941D61.2090800@dynamicsoft.com> <3F942533.1000303@cisco.com> <3F94E61D.3010406@nokia.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 21 Oct 2003 08:27:17.0746 (UTC) FILETIME=[23837520:01C397AD] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:27:11 +0300 Hi,, Aki Niemi writes: >I think the way round this problem could be that a) we get rid of >retransmissions, and b) base the request timeout on both connection activity >and a timer. If a request was sent, and the connection stays inactive for >the timer to fire, only then would the client assume the session has failed, >and proceed with tear down. I think we have a problem here because of relays. Even if you have sent your message completely and the relay has received it via TCP, it does not mean that the whole message has been relayed, even if we assume cut-through relaying. Two relays make it worse: there is 3 TCP send buffers and receive buffer between sender and recipient. If we add timer, we also need some kind of keepalive messages that can be sent while receiving a large message. 100 Continue? Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 07:01:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13091; Tue, 21 Oct 2003 07:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABuH6-0002BG-00; Tue, 21 Oct 2003 07:02:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABuH6-0002BB-00; Tue, 21 Oct 2003 07:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuH4-0004FI-JN; Tue, 21 Oct 2003 07:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuGc-00045E-M9 for simple@optimus.ietf.org; Tue, 21 Oct 2003 07:01:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13079 for ; Tue, 21 Oct 2003 07:01:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABuGY-0002B0-00 for simple@ietf.org; Tue, 21 Oct 2003 07:01:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABuGX-0002Aw-00 for simple@ietf.org; Tue, 21 Oct 2003 07:01:29 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9LB1Ud06387 for ; Tue, 21 Oct 2003 14:01:30 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 14:01:30 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 14:01:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972D7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOXrSVsZTtpjNkcTKi/PXm5MvDV3AAE8L2g To: , Cc: , , X-OriginalArrivalTime: 21 Oct 2003 11:01:29.0947 (UTC) FILETIME=[AE414AB0:01C397C2] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 14:01:29 +0300 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Tuesday, October 21, 2003 11:27 AM > To: Niemi Aki (NMP/Helsinki) > Cc: ext Paul Kyzivat; Ben Campbell; Khartabil Hisham=20 > (NMP-MSW/Helsinki); > simple@ietf.org > Subject: Re: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 > Hi,, >=20 > Aki Niemi writes: > >I think the way round this problem could be that a) we get rid of > >retransmissions, and b) base the request timeout on both=20 > connection activity > >and a timer. If a request was sent, and the connection stays=20 > inactive for > >the timer to fire, only then would the client assume the=20 > session has failed, > >and proceed with tear down. >=20 > I think we have a problem here because of relays. Even if you=20 > have sent > your message completely and the relay has received it via TCP, it > does not mean that the whole message has been relayed, even=20 > if we assume > cut-through relaying. Two relays make it worse: there is 3 TCP send > buffers and receive buffer between sender and recipient. Yes, the sender might have a fast uplink and the receiver might have a = slow downlink, so relying on a timer is not enough (so my earlier = suggestion is not sufficient on its own). >=20 > If we add timer, we also need some kind of keepalive messages that can > be sent while receiving a large message. 100 Continue? Not a bad idea. But the timer should be standardised so that the = receiver can send the 100 responses before the sender times out. /Hisham >=20 > Pekka >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 07:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13108 for ; Tue, 21 Oct 2003 07:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuHB-0004Hc-Tz for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 07:02:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LB29Yu016463 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 07:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuHB-0004HS-LC for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 07:02:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13091; Tue, 21 Oct 2003 07:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABuH6-0002BG-00; Tue, 21 Oct 2003 07:02:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABuH6-0002BB-00; Tue, 21 Oct 2003 07:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuH4-0004FI-JN; Tue, 21 Oct 2003 07:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuGc-00045E-M9 for simple@optimus.ietf.org; Tue, 21 Oct 2003 07:01:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13079 for ; Tue, 21 Oct 2003 07:01:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABuGY-0002B0-00 for simple@ietf.org; Tue, 21 Oct 2003 07:01:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABuGX-0002Aw-00 for simple@ietf.org; Tue, 21 Oct 2003 07:01:29 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9LB1Ud06387 for ; Tue, 21 Oct 2003 14:01:30 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 14:01:30 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 14:01:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - request/response handling and retrying Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017972D7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - request/response handling and retrying Thread-Index: AcOXrSVsZTtpjNkcTKi/PXm5MvDV3AAE8L2g To: , Cc: , , X-OriginalArrivalTime: 21 Oct 2003 11:01:29.0947 (UTC) FILETIME=[AE414AB0:01C397C2] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 14:01:29 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Tuesday, October 21, 2003 11:27 AM > To: Niemi Aki (NMP/Helsinki) > Cc: ext Paul Kyzivat; Ben Campbell; Khartabil Hisham=20 > (NMP-MSW/Helsinki); > simple@ietf.org > Subject: Re: [Simple] MSRP comments - request/response handling and > retrying >=20 >=20 > Hi,, >=20 > Aki Niemi writes: > >I think the way round this problem could be that a) we get rid of > >retransmissions, and b) base the request timeout on both=20 > connection activity > >and a timer. If a request was sent, and the connection stays=20 > inactive for > >the timer to fire, only then would the client assume the=20 > session has failed, > >and proceed with tear down. >=20 > I think we have a problem here because of relays. Even if you=20 > have sent > your message completely and the relay has received it via TCP, it > does not mean that the whole message has been relayed, even=20 > if we assume > cut-through relaying. Two relays make it worse: there is 3 TCP send > buffers and receive buffer between sender and recipient. Yes, the sender might have a fast uplink and the receiver might have a = slow downlink, so relying on a timer is not enough (so my earlier = suggestion is not sufficient on its own). >=20 > If we add timer, we also need some kind of keepalive messages that can > be sent while receiving a large message. 100 Continue? Not a bad idea. But the timer should be standardised so that the = receiver can send the 100 responses before the sender times out. /Hisham >=20 > Pekka >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 11:18:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22926; Tue, 21 Oct 2003 11:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByGz-0004tc-00; Tue, 21 Oct 2003 11:18:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByGy-0004tZ-00; Tue, 21 Oct 2003 11:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByGm-0007CJ-Vw; Tue, 21 Oct 2003 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByGV-00077Q-6O for simple@optimus.ietf.org; Tue, 21 Oct 2003 11:17:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22915 for ; Tue, 21 Oct 2003 11:17:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByGU-0004tJ-00 for simple@ietf.org; Tue, 21 Oct 2003 11:17:42 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AByGT-0004tG-00 for simple@ietf.org; Tue, 21 Oct 2003 11:17:41 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9LFHQF8012033; Tue, 21 Oct 2003 10:17:33 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F954DF6.1090002@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP comments - security References: <3F94ED7F.5050700@nokia.com> In-Reply-To: <3F94ED7F.5050700@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 10:17:10 -0500 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > A couple more things came to mind about MSRP security. There are > multiple authentication mechanisms available (digest, TLS > authentication), as well as potentially many digest algorithms available > (SHA1, plus extensibility). > > First of all, the security considerations should probably say something > about authenticating with multiple mechanisms, and the vulnerabilities > this might introduce. For example, TLS could be used to authenticate the > server, and then digest could be used to authenticate the client after > the TLS tunnel is established. There is potential for a MITM attack, if > these same digest credentials are ever used without the TLS tunnel [1]. I agree we could use a little more here. However, at this point anything like this will probably need to be listed as an open issue in the draft version I am currently trying to get out the door. > > Secondly, the digest mechanism has extensibility for other digest > algorithms, yet the SChal "algorithm" parameter is single valued. This > is a problem, since the client has no way to indicate the server > challenge contained an algorithm it does not support. Hence there needs > to be a way to negotiate the used algorithm, e.g., by the server > challenging with a list, and the client then picking one from that list. > We made an explicit decision in Ottowa not to allow digest extensibility. > Furthermore, if negotiation of the used algorithm isn't secure, there is > a possibility for a bidding down attack. > > So, my proposal is to modify the SChal so that the algorithm field is > multi-valued, and this field is also included in the request-digest. The > algorithm field in the CAuth then again needs to be single-valued, to > indicate which algorithm was chosen by the client. > > Regards, > Aki > > [1] http://eprint.iacr.org/2002/163/ > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 11:18:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22944 for ; Tue, 21 Oct 2003 11:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByH0-0007GL-Lu for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 11:18:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFIEJu027916 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 11:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByH0-0007GB-Ij for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:18:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22926; Tue, 21 Oct 2003 11:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByGz-0004tc-00; Tue, 21 Oct 2003 11:18:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByGy-0004tZ-00; Tue, 21 Oct 2003 11:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByGm-0007CJ-Vw; Tue, 21 Oct 2003 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByGV-00077Q-6O for simple@optimus.ietf.org; Tue, 21 Oct 2003 11:17:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22915 for ; Tue, 21 Oct 2003 11:17:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByGU-0004tJ-00 for simple@ietf.org; Tue, 21 Oct 2003 11:17:42 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AByGT-0004tG-00 for simple@ietf.org; Tue, 21 Oct 2003 11:17:41 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9LFHQF8012033; Tue, 21 Oct 2003 10:17:33 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F954DF6.1090002@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] MSRP comments - security References: <3F94ED7F.5050700@nokia.com> In-Reply-To: <3F94ED7F.5050700@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 10:17:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > A couple more things came to mind about MSRP security. There are > multiple authentication mechanisms available (digest, TLS > authentication), as well as potentially many digest algorithms available > (SHA1, plus extensibility). > > First of all, the security considerations should probably say something > about authenticating with multiple mechanisms, and the vulnerabilities > this might introduce. For example, TLS could be used to authenticate the > server, and then digest could be used to authenticate the client after > the TLS tunnel is established. There is potential for a MITM attack, if > these same digest credentials are ever used without the TLS tunnel [1]. I agree we could use a little more here. However, at this point anything like this will probably need to be listed as an open issue in the draft version I am currently trying to get out the door. > > Secondly, the digest mechanism has extensibility for other digest > algorithms, yet the SChal "algorithm" parameter is single valued. This > is a problem, since the client has no way to indicate the server > challenge contained an algorithm it does not support. Hence there needs > to be a way to negotiate the used algorithm, e.g., by the server > challenging with a list, and the client then picking one from that list. > We made an explicit decision in Ottowa not to allow digest extensibility. > Furthermore, if negotiation of the used algorithm isn't secure, there is > a possibility for a bidding down attack. > > So, my proposal is to modify the SChal so that the algorithm field is > multi-valued, and this field is also included in the request-digest. The > algorithm field in the CAuth then again needs to be single-valued, to > indicate which algorithm was chosen by the client. > > Regards, > Aki > > [1] http://eprint.iacr.org/2002/163/ > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 11:39:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23794; Tue, 21 Oct 2003 11:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABycC-00059c-00; Tue, 21 Oct 2003 11:40:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABycC-00059Z-00; Tue, 21 Oct 2003 11:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByc6-0005Xa-V0; Tue, 21 Oct 2003 11:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABybg-0005Op-Vf for simple@optimus.ietf.org; Tue, 21 Oct 2003 11:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23779 for ; Tue, 21 Oct 2003 11:39:25 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABybf-00059O-00 for simple@ietf.org; Tue, 21 Oct 2003 11:39:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABybf-00059L-00 for simple@ietf.org; Tue, 21 Oct 2003 11:39:35 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9LFdWX19090 for ; Tue, 21 Oct 2003 18:39:33 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 18:37:41 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 18:37:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - security Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - security Thread-Index: AcOX5nxuZ4UJS87MQVOqfYt8hQSXTgAAa7Pg To: Cc: X-OriginalArrivalTime: 21 Oct 2003 15:37:39.0518 (UTC) FILETIME=[427D2DE0:01C397E9] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 18:37:39 +0300 Content-Transfer-Encoding: quoted-printable > > Secondly, the digest mechanism has extensibility for other digest=20 > > algorithms, yet the SChal "algorithm" parameter is single=20 > valued. This=20 > > is a problem, since the client has no way to indicate the server=20 > > challenge contained an algorithm it does not support.=20 > Hence there needs=20 > > to be a way to negotiate the used algorithm, e.g., by the server=20 > > challenging with a list, and the client then picking one=20 > from that list. > >=20 >=20 > We made an explicit decision in Ottowa not to allow digest=20 > extensibility. Well, that's not what the draft currently has. You need to then remove = the "algorithm" directive, and all text talking about adding new = algorithms - *if* you think SHA1 will never need to be replaced with = anything else, that is. Regards, Aki=20 >=20 > > Furthermore, if negotiation of the used algorithm isn't=20 > secure, there is=20 > > a possibility for a bidding down attack. > >=20 > > So, my proposal is to modify the SChal so that the=20 > algorithm field is=20 > > multi-valued, and this field is also included in the=20 > request-digest. The=20 > > algorithm field in the CAuth then again needs to be=20 > single-valued, to=20 > > indicate which algorithm was chosen by the client. > >=20 > > Regards, > > Aki > >=20 > > [1] http://eprint.iacr.org/2002/163/ > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 11:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23836 for ; Tue, 21 Oct 2003 11:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABycF-0005b5-OX for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 11:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFeBua021502 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 11:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABycE-0005aa-Bd for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23794; Tue, 21 Oct 2003 11:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABycC-00059c-00; Tue, 21 Oct 2003 11:40:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABycC-00059Z-00; Tue, 21 Oct 2003 11:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByc6-0005Xa-V0; Tue, 21 Oct 2003 11:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABybg-0005Op-Vf for simple@optimus.ietf.org; Tue, 21 Oct 2003 11:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23779 for ; Tue, 21 Oct 2003 11:39:25 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABybf-00059O-00 for simple@ietf.org; Tue, 21 Oct 2003 11:39:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ABybf-00059L-00 for simple@ietf.org; Tue, 21 Oct 2003 11:39:35 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9LFdWX19090 for ; Tue, 21 Oct 2003 18:39:33 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 18:37:41 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 18:37:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP comments - security Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP comments - security Thread-Index: AcOX5nxuZ4UJS87MQVOqfYt8hQSXTgAAa7Pg To: Cc: X-OriginalArrivalTime: 21 Oct 2003 15:37:39.0518 (UTC) FILETIME=[427D2DE0:01C397E9] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 18:37:39 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Secondly, the digest mechanism has extensibility for other digest=20 > > algorithms, yet the SChal "algorithm" parameter is single=20 > valued. This=20 > > is a problem, since the client has no way to indicate the server=20 > > challenge contained an algorithm it does not support.=20 > Hence there needs=20 > > to be a way to negotiate the used algorithm, e.g., by the server=20 > > challenging with a list, and the client then picking one=20 > from that list. > >=20 >=20 > We made an explicit decision in Ottowa not to allow digest=20 > extensibility. Well, that's not what the draft currently has. You need to then remove = the "algorithm" directive, and all text talking about adding new = algorithms - *if* you think SHA1 will never need to be replaced with = anything else, that is. Regards, Aki=20 >=20 > > Furthermore, if negotiation of the used algorithm isn't=20 > secure, there is=20 > > a possibility for a bidding down attack. > >=20 > > So, my proposal is to modify the SChal so that the=20 > algorithm field is=20 > > multi-valued, and this field is also included in the=20 > request-digest. The=20 > > algorithm field in the CAuth then again needs to be=20 > single-valued, to=20 > > indicate which algorithm was chosen by the client. > >=20 > > Regards, > > Aki > >=20 > > [1] http://eprint.iacr.org/2002/163/ > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 15:59:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04346; Tue, 21 Oct 2003 15:59:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2ey-0000YC-00; Tue, 21 Oct 2003 15:59:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2ey-0000Y9-00; Tue, 21 Oct 2003 15:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2ei-00005y-NB; Tue, 21 Oct 2003 15:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2dn-00087k-QS for simple@optimus.ietf.org; Tue, 21 Oct 2003 15:58:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04041; Tue, 21 Oct 2003 15:57:52 -0400 (EDT) Message-Id: <200310211957.PAA04041@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-winfo-history-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 15:57:52 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension for Watcher Information History Author(s) : A. Niemi, et. al. Filename : draft-niemi-simple-winfo-history-00.txt Pages : 13 Date : 2003-10-21 This document defines an extension to the Session Initiation Protocol (SIP) watcher information template-package. This extension enables a subscriber to request for a list of past watcher information events over some time period. This document defines a mechanism for requesting watcher information history in subscriptions to the watcherinfo template-package. It also defines an extension to the watcher information data format for representing this history information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-winfo-history-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-niemi-simple-winfo-history-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-niemi-simple-winfo-history-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21153328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-winfo-history-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-winfo-history-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 15:59:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04446 for ; Tue, 21 Oct 2003 15:59:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2f0-0000GW-Uw for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 15:59:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LJxIqZ000989 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 15:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2f0-0000Fa-Mm for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 15:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04346; Tue, 21 Oct 2003 15:59:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2ey-0000YC-00; Tue, 21 Oct 2003 15:59:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2ey-0000Y9-00; Tue, 21 Oct 2003 15:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2ei-00005y-NB; Tue, 21 Oct 2003 15:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2dn-00087k-QS for simple@optimus.ietf.org; Tue, 21 Oct 2003 15:58:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04041; Tue, 21 Oct 2003 15:57:52 -0400 (EDT) Message-Id: <200310211957.PAA04041@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-winfo-history-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 15:57:52 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension for Watcher Information History Author(s) : A. Niemi, et. al. Filename : draft-niemi-simple-winfo-history-00.txt Pages : 13 Date : 2003-10-21 This document defines an extension to the Session Initiation Protocol (SIP) watcher information template-package. This extension enables a subscriber to request for a list of past watcher information events over some time period. This document defines a mechanism for requesting watcher information history in subscriptions to the watcherinfo template-package. It also defines an extension to the watcher information data format for representing this history information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-winfo-history-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-niemi-simple-winfo-history-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-niemi-simple-winfo-history-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21153328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-winfo-history-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-winfo-history-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 21 15:59:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04523; Tue, 21 Oct 2003 15:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2fm-0000ZY-00; Tue, 21 Oct 2003 16:00:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2fl-0000ZV-00; Tue, 21 Oct 2003 16:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fm-0000bq-8m; Tue, 21 Oct 2003 16:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2f6-0000IJ-KW for simple@optimus.ietf.org; Tue, 21 Oct 2003 15:59:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04384; Tue, 21 Oct 2003 15:59:13 -0400 (EDT) Message-Id: <200310211959.PAA04384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-im-wireless-reqs-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 15:59:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Instant Messaging in 3GPP Wireless Systems Author(s) : A. Niemi Filename : draft-niemi-simple-im-wireless-reqs-02.txt Pages : 12 Date : 2003-10-21 This document lists the requirements specific to 3GPP wireless Instant Messaging systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-niemi-simple-im-wireless-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21153737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-im-wireless-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153737.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 21 16:00:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04694 for ; Tue, 21 Oct 2003 16:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fq-0000pg-S8 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 16:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LK0AVF003095 for simple-archive@odin.ietf.org; Tue, 21 Oct 2003 16:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fo-0000f4-DG for simple-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 16:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04523; Tue, 21 Oct 2003 15:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2fm-0000ZY-00; Tue, 21 Oct 2003 16:00:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2fl-0000ZV-00; Tue, 21 Oct 2003 16:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fm-0000bq-8m; Tue, 21 Oct 2003 16:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2f6-0000IJ-KW for simple@optimus.ietf.org; Tue, 21 Oct 2003 15:59:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04384; Tue, 21 Oct 2003 15:59:13 -0400 (EDT) Message-Id: <200310211959.PAA04384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-im-wireless-reqs-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 15:59:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Instant Messaging in 3GPP Wireless Systems Author(s) : A. Niemi Filename : draft-niemi-simple-im-wireless-reqs-02.txt Pages : 12 Date : 2003-10-21 This document lists the requirements specific to 3GPP wireless Instant Messaging systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-niemi-simple-im-wireless-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21153737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-im-wireless-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153737.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 22 10:30:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11813; Wed, 22 Oct 2003 10:30:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACK09-0005zT-00; Wed, 22 Oct 2003 10:30:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACK09-0005zH-00; Wed, 22 Oct 2003 10:30:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJzu-00058t-17; Wed, 22 Oct 2003 10:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJza-00054d-4W for simple@optimus.ietf.org; Wed, 22 Oct 2003 10:29:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11772 for ; Wed, 22 Oct 2003 10:29:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJzX-0005yN-00 for simple@ietf.org; Wed, 22 Oct 2003 10:29:39 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ACJzW-0005x3-00 for simple@ietf.org; Wed, 22 Oct 2003 10:29:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9MET6d16203 for ; Wed, 22 Oct 2003 09:29:06 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: multipart/mixed; boundary="=-pD5LZFi0dIDxYRblFjpy" Message-Id: <1066832944.936.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Subject: [Simple] [Fwd: I-D ACTION:draft-sparks-simple-pdoc-usage-00.txt] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 09:29:04 -0500 --=-pD5LZFi0dIDxYRblFjpy Content-Type: text/plain Content-Transfer-Encoding: 7bit -----Forwarded Message----- > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-sparks-simple-pdoc-usage-00.txt > Date: Mon, 20 Oct 2003 15:43:19 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SIMPLE Presence Document Usage Examples > Author(s) : R. Sparks > Filename : draft-sparks-simple-pdoc-usage-00.txt > Pages : 26 > Date : 2003-10-20 > > This draft details several use-cases of systems using SIMPLE presence > documents. It explores the interaction of systems with different > requirements and assumptions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sparks-simple-pdoc-usage-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-sparks-simple-pdoc-usage-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-sparks-simple-pdoc-usage-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --=-pD5LZFi0dIDxYRblFjpy Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-20145020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sparks-simple-pdoc-usage-00.txt --=-pD5LZFi0dIDxYRblFjpy Content-Type: Message/External-body; name="draft-sparks-simple-pdoc-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit --=-pD5LZFi0dIDxYRblFjpy-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 22 10:30:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11887 for ; Wed, 22 Oct 2003 10:30:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK0C-0005I1-G9 for simple-archive@odin.ietf.org; Wed, 22 Oct 2003 10:30:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MEUKZM020329 for simple-archive@odin.ietf.org; Wed, 22 Oct 2003 10:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK0C-0005Ho-Ct for simple-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 10:30:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11813; Wed, 22 Oct 2003 10:30:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACK09-0005zT-00; Wed, 22 Oct 2003 10:30:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACK09-0005zH-00; Wed, 22 Oct 2003 10:30:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJzu-00058t-17; Wed, 22 Oct 2003 10:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJza-00054d-4W for simple@optimus.ietf.org; Wed, 22 Oct 2003 10:29:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11772 for ; Wed, 22 Oct 2003 10:29:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJzX-0005yN-00 for simple@ietf.org; Wed, 22 Oct 2003 10:29:39 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ACJzW-0005x3-00 for simple@ietf.org; Wed, 22 Oct 2003 10:29:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9MET6d16203 for ; Wed, 22 Oct 2003 09:29:06 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: multipart/mixed; boundary="=-pD5LZFi0dIDxYRblFjpy" Message-Id: <1066832944.936.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Subject: [Simple] [Fwd: I-D ACTION:draft-sparks-simple-pdoc-usage-00.txt] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 09:29:04 -0500 --=-pD5LZFi0dIDxYRblFjpy Content-Type: text/plain Content-Transfer-Encoding: 7bit -----Forwarded Message----- > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-sparks-simple-pdoc-usage-00.txt > Date: Mon, 20 Oct 2003 15:43:19 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SIMPLE Presence Document Usage Examples > Author(s) : R. Sparks > Filename : draft-sparks-simple-pdoc-usage-00.txt > Pages : 26 > Date : 2003-10-20 > > This draft details several use-cases of systems using SIMPLE presence > documents. It explores the interaction of systems with different > requirements and assumptions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sparks-simple-pdoc-usage-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-sparks-simple-pdoc-usage-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-sparks-simple-pdoc-usage-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --=-pD5LZFi0dIDxYRblFjpy Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-20145020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sparks-simple-pdoc-usage-00.txt --=-pD5LZFi0dIDxYRblFjpy Content-Type: Message/External-body; name="draft-sparks-simple-pdoc-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit --=-pD5LZFi0dIDxYRblFjpy-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 22 16:43:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27255; Wed, 22 Oct 2003 16:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPpw-0002QU-00; Wed, 22 Oct 2003 16:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPpv-0002QR-00; Wed, 22 Oct 2003 16:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPpo-0003o3-PJ; Wed, 22 Oct 2003 16:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPpC-0003ga-CJ for simple@optimus.ietf.org; Wed, 22 Oct 2003 16:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27228 for ; Wed, 22 Oct 2003 16:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPpA-0002QD-00 for simple@ietf.org; Wed, 22 Oct 2003 16:43:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACPp9-0002Q8-00 for simple@ietf.org; Wed, 22 Oct 2003 16:43:19 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9MKh7F8056863; Wed, 22 Oct 2003 15:43:12 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F96EBC1.9060401@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP comments - security References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 15:42:41 -0500 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > > Secondly, the digest mechanism has extensibility for other digest > > > algorithms, yet the SChal "algorithm" parameter is single > > valued. This > > > is a problem, since the client has no way to indicate the server > > > challenge contained an algorithm it does not support. > > Hence there needs > > > to be a way to negotiate the used algorithm, e.g., by the server > > > challenging with a list, and the client then picking one > > from that list. > > > > > > > We made an explicit decision in Ottowa not to allow digest > > extensibility. > > Well, that's not what the draft currently has. You need to then remove the "algorithm" directive, and all text talking about adding new algorithms - *if* you think SHA1 will never need to be replaced with anything else, that is. Sorry, my brain was asleppt when I wrote that. We explicitly decided not all mechanism extensibility where you could create mechanisms other than digest. I don't think we decided to forever limit digest to SHA1. (The minutes from Ottawa are not clear on this--does anyone remember differently?) > > Regards, > Aki > > > > > > Furthermore, if negotiation of the used algorithm isn't > > secure, there is > > > a possibility for a bidding down attack. > > > > > > So, my proposal is to modify the SChal so that the > > algorithm field is > > > multi-valued, and this field is also included in the > > request-digest. The > > > algorithm field in the CAuth then again needs to be > > single-valued, to > > > indicate which algorithm was chosen by the client. > > > > > > Regards, > > > Aki > > > > > > [1] http://eprint.iacr.org/2002/163/ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 22 16:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27291 for ; Wed, 22 Oct 2003 16:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPpz-0003qx-MV for simple-archive@odin.ietf.org; Wed, 22 Oct 2003 16:44:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKiB8A014807 for simple-archive@odin.ietf.org; Wed, 22 Oct 2003 16:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPpz-0003qk-HZ for simple-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27255; Wed, 22 Oct 2003 16:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPpw-0002QU-00; Wed, 22 Oct 2003 16:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPpv-0002QR-00; Wed, 22 Oct 2003 16:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPpo-0003o3-PJ; Wed, 22 Oct 2003 16:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPpC-0003ga-CJ for simple@optimus.ietf.org; Wed, 22 Oct 2003 16:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27228 for ; Wed, 22 Oct 2003 16:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPpA-0002QD-00 for simple@ietf.org; Wed, 22 Oct 2003 16:43:20 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACPp9-0002Q8-00 for simple@ietf.org; Wed, 22 Oct 2003 16:43:19 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9MKh7F8056863; Wed, 22 Oct 2003 15:43:12 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F96EBC1.9060401@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP comments - security References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 15:42:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > > Secondly, the digest mechanism has extensibility for other digest > > > algorithms, yet the SChal "algorithm" parameter is single > > valued. This > > > is a problem, since the client has no way to indicate the server > > > challenge contained an algorithm it does not support. > > Hence there needs > > > to be a way to negotiate the used algorithm, e.g., by the server > > > challenging with a list, and the client then picking one > > from that list. > > > > > > > We made an explicit decision in Ottowa not to allow digest > > extensibility. > > Well, that's not what the draft currently has. You need to then remove the "algorithm" directive, and all text talking about adding new algorithms - *if* you think SHA1 will never need to be replaced with anything else, that is. Sorry, my brain was asleppt when I wrote that. We explicitly decided not all mechanism extensibility where you could create mechanisms other than digest. I don't think we decided to forever limit digest to SHA1. (The minutes from Ottawa are not clear on this--does anyone remember differently?) > > Regards, > Aki > > > > > > Furthermore, if negotiation of the used algorithm isn't > > secure, there is > > > a possibility for a bidding down attack. > > > > > > So, my proposal is to modify the SChal so that the > > algorithm field is > > > multi-valued, and this field is also included in the > > request-digest. The > > > algorithm field in the CAuth then again needs to be > > single-valued, to > > > indicate which algorithm was chosen by the client. > > > > > > Regards, > > > Aki > > > > > > [1] http://eprint.iacr.org/2002/163/ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 22 18:02:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29916; Wed, 22 Oct 2003 18:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR4N-0003EY-00; Wed, 22 Oct 2003 18:03:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACR4N-0003EV-00; Wed, 22 Oct 2003 18:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR4H-0002uw-7t; Wed, 22 Oct 2003 18:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR3u-0002rh-6Q for simple@optimus.ietf.org; Wed, 22 Oct 2003 18:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29895 for ; Wed, 22 Oct 2003 18:02:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR3r-0003ER-00 for simple@ietf.org; Wed, 22 Oct 2003 18:02:35 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACR3q-0003EM-00 for simple@ietf.org; Wed, 22 Oct 2003 18:02:34 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9MM2BF8064538; Wed, 22 Oct 2003 17:02:22 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F96FE49.30306@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - security References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> <3F96EBC1.9060401@dynamicsoft.com> In-Reply-To: <3F96EBC1.9060401@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 17:01:45 -0500 Content-Transfer-Encoding: 7bit (replying to self) Actually, the I think the syntax allows for more than one algorithm in the challenge. Aki is correct that we have no mechanism for the client to say that it does not support an algorithm. Is it sufficient to say that all devices MUST support SHA1, and that if any algorithms are specified at all in the challenge, then SHA1 MUSt be included? Ben Campbell wrote: > aki.niemi@nokia.com wrote: > >> > > Secondly, the digest mechanism has extensibility for other digest >> > > algorithms, yet the SChal "algorithm" parameter is single > >> valued. This > > is a problem, since the client has no way to >> indicate the server > > challenge contained an algorithm it does not >> support. > Hence there needs > > to be a way to negotiate the used >> algorithm, e.g., by the server > > challenging with a list, and the >> client then picking one > from that list. >> > > > > We made an explicit decision in Ottowa not to allow digest >> > extensibility. >> >> Well, that's not what the draft currently has. You need to then remove >> the "algorithm" directive, and all text talking about adding new >> algorithms - *if* you think SHA1 will never need to be replaced with >> anything else, that is. > > > Sorry, my brain was asleppt when I wrote that. We explicitly decided not > all mechanism extensibility where you could create mechanisms other than > digest. I don't think we decided to forever limit digest to SHA1. > > (The minutes from Ottawa are not clear on this--does anyone remember > differently?) > >> >> Regards, >> Aki >> > > > Furthermore, if negotiation of the used algorithm isn't > >> secure, there is > > a possibility for a bidding down attack. >> > > > > So, my proposal is to modify the SChal so that the > >> algorithm field is > > multi-valued, and this field is also included >> in the > request-digest. The > > algorithm field in the CAuth then >> again needs to be > single-valued, to > > indicate which algorithm >> was chosen by the client. >> > > > > Regards, >> > > Aki >> > > > > [1] http://eprint.iacr.org/2002/163/ >> > > > > > > > > > > > > > > >> _______________________________________________ >> > > Simple mailing list >> > > Simple@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/simple >> > > > >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 22 18:03:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29946 for ; Wed, 22 Oct 2003 18:03:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR4R-0002xE-31 for simple-archive@odin.ietf.org; Wed, 22 Oct 2003 18:03:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MM3BYE011350 for simple-archive@odin.ietf.org; Wed, 22 Oct 2003 18:03:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR4Q-0002wz-Tu for simple-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 18:03:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29916; Wed, 22 Oct 2003 18:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR4N-0003EY-00; Wed, 22 Oct 2003 18:03:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACR4N-0003EV-00; Wed, 22 Oct 2003 18:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR4H-0002uw-7t; Wed, 22 Oct 2003 18:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR3u-0002rh-6Q for simple@optimus.ietf.org; Wed, 22 Oct 2003 18:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29895 for ; Wed, 22 Oct 2003 18:02:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR3r-0003ER-00 for simple@ietf.org; Wed, 22 Oct 2003 18:02:35 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACR3q-0003EM-00 for simple@ietf.org; Wed, 22 Oct 2003 18:02:34 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9MM2BF8064538; Wed, 22 Oct 2003 17:02:22 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F96FE49.30306@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP comments - security References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59287@esebe013.ntc.nokia.com> <3F96EBC1.9060401@dynamicsoft.com> In-Reply-To: <3F96EBC1.9060401@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 17:01:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (replying to self) Actually, the I think the syntax allows for more than one algorithm in the challenge. Aki is correct that we have no mechanism for the client to say that it does not support an algorithm. Is it sufficient to say that all devices MUST support SHA1, and that if any algorithms are specified at all in the challenge, then SHA1 MUSt be included? Ben Campbell wrote: > aki.niemi@nokia.com wrote: > >> > > Secondly, the digest mechanism has extensibility for other digest >> > > algorithms, yet the SChal "algorithm" parameter is single > >> valued. This > > is a problem, since the client has no way to >> indicate the server > > challenge contained an algorithm it does not >> support. > Hence there needs > > to be a way to negotiate the used >> algorithm, e.g., by the server > > challenging with a list, and the >> client then picking one > from that list. >> > > > > We made an explicit decision in Ottowa not to allow digest >> > extensibility. >> >> Well, that's not what the draft currently has. You need to then remove >> the "algorithm" directive, and all text talking about adding new >> algorithms - *if* you think SHA1 will never need to be replaced with >> anything else, that is. > > > Sorry, my brain was asleppt when I wrote that. We explicitly decided not > all mechanism extensibility where you could create mechanisms other than > digest. I don't think we decided to forever limit digest to SHA1. > > (The minutes from Ottawa are not clear on this--does anyone remember > differently?) > >> >> Regards, >> Aki >> > > > Furthermore, if negotiation of the used algorithm isn't > >> secure, there is > > a possibility for a bidding down attack. >> > > > > So, my proposal is to modify the SChal so that the > >> algorithm field is > > multi-valued, and this field is also included >> in the > request-digest. The > > algorithm field in the CAuth then >> again needs to be > single-valued, to > > indicate which algorithm >> was chosen by the client. >> > > > > Regards, >> > > Aki >> > > > > [1] http://eprint.iacr.org/2002/163/ >> > > > > > > > > > > > > > > >> _______________________________________________ >> > > Simple mailing list >> > > Simple@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/simple >> > > > >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 23 12:14:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03622; Thu, 23 Oct 2003 12:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi6H-0003nZ-00; Thu, 23 Oct 2003 12:14:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACi6H-0003nU-00; Thu, 23 Oct 2003 12:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi65-0007Zn-JA; Thu, 23 Oct 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi5x-0007Up-Eb for simple@optimus.ietf.org; Thu, 23 Oct 2003 12:13:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03576; Thu, 23 Oct 2003 12:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi5v-0003mK-00; Thu, 23 Oct 2003 12:13:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ACi5u-0003lG-00; Thu, 23 Oct 2003 12:13:51 -0400 Received: from localhost.cisco.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9NGDBd09030; Thu, 23 Oct 2003 11:13:11 -0500 From: Robert Sparks To: simple@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1066925585.11527.12.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Registration is now open for SIPIt 14 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 11:13:05 -0500 Content-Transfer-Encoding: 7bit SIPIt 14 will take place February 8-13 in Cannes, France. The event will be hosted by by ETSI. More details and registration are available at http://www.etsi.org/plugtests/SIPIT14.htm >From Philippe Cousin at ETSI Plugtests: ETSI is happy to host the SIPit event again and to provide its free support to the SIP community. Sponsors are welcome either to support the global event or for the social event. Should your company be interested to helping sponser this nice event, please contact philippe.cousin@etsi.org RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 23 12:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03668 for ; Thu, 23 Oct 2003 12:14:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi6J-0007e7-Bg for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 12:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGEFuk029385 for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 12:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi6J-0007ds-6o for simple-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 12:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03622; Thu, 23 Oct 2003 12:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi6H-0003nZ-00; Thu, 23 Oct 2003 12:14:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACi6H-0003nU-00; Thu, 23 Oct 2003 12:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi65-0007Zn-JA; Thu, 23 Oct 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi5x-0007Up-Eb for simple@optimus.ietf.org; Thu, 23 Oct 2003 12:13:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03576; Thu, 23 Oct 2003 12:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi5v-0003mK-00; Thu, 23 Oct 2003 12:13:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ACi5u-0003lG-00; Thu, 23 Oct 2003 12:13:51 -0400 Received: from localhost.cisco.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9NGDBd09030; Thu, 23 Oct 2003 11:13:11 -0500 From: Robert Sparks To: simple@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1066925585.11527.12.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Registration is now open for SIPIt 14 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 11:13:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIPIt 14 will take place February 8-13 in Cannes, France. The event will be hosted by by ETSI. More details and registration are available at http://www.etsi.org/plugtests/SIPIT14.htm >From Philippe Cousin at ETSI Plugtests: ETSI is happy to host the SIPit event again and to provide its free support to the SIP community. Sponsors are welcome either to support the global event or for the social event. Should your company be interested to helping sponser this nice event, please contact philippe.cousin@etsi.org RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 23 12:15:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03806; Thu, 23 Oct 2003 12:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi83-0003rX-00; Thu, 23 Oct 2003 12:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACi82-0003rU-00; Thu, 23 Oct 2003 12:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi81-00087j-MM; Thu, 23 Oct 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi7x-00086p-Mv for simple@optimus.ietf.org; Thu, 23 Oct 2003 12:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03764 for ; Thu, 23 Oct 2003 12:15:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi7w-0003qa-00 for simple@ietf.org; Thu, 23 Oct 2003 12:15:56 -0400 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1ACi7u-0003qM-00 for simple@ietf.org; Thu, 23 Oct 2003 12:15:55 -0400 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Thu, 23 Oct 2003 21:50:36 +0530 Delivered-To: ipgen-india.com-sunku@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 3969 invoked by uid 7010); Thu Oct 23 21:38:59 2003 Received: (sifymail 3967 invoked by uid 7010); 23 Oct 2003 21:38:59 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 23 Oct 2003 21:38:59 +0530 Received: (sifymail 5854 invoked by uid 7005); 23 Oct 2003 21:38:59 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 23 Oct 2003 21:38:59 +0530 Received: (sifymail 5849 invoked by uid 7005); 23 Oct 2003 21:38:58 +0530 Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73) by 202.144.76.19 with SMTP; 23 Oct 2003 21:38:58 +0530 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1ACi6A-000082-00; Thu, 23 Oct 2003 12:14:06 -0400 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NGDvLZ029396 for ; Thu, 23 Oct 2003 12:13:58 -0400 (EDT) Received: from localhost.cisco.com (localhost.localdomain [127.0.0.1]) id h9NGDBd09030; Thu, 23 Oct 2003 11:13:11 -0500 From: Robert Sparks To: simple@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1066925585.11527.12.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip-implementors] Registration is now open for SIPIt 14 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 11:13:05 -0500 Content-Transfer-Encoding: 7bit SIPIt 14 will take place February 8-13 in Cannes, France. The event will be hosted by by ETSI. More details and registration are available at http://www.etsi.org/plugtests/SIPIT14.htm >From Philippe Cousin at ETSI Plugtests: ETSI is happy to host the SIPit event again and to provide its free support to the SIP community. Sponsors are welcome either to support the global event or for the social event. Should your company be interested to helping sponser this nice event, please contact philippe.cousin@etsi.org RjS _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 23 12:16:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03986 for ; Thu, 23 Oct 2003 12:16:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi85-0008AV-5q for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 12:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGG58Y031393 for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 12:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi85-0008AG-2K for simple-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 12:16:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03806; Thu, 23 Oct 2003 12:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi83-0003rX-00; Thu, 23 Oct 2003 12:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACi82-0003rU-00; Thu, 23 Oct 2003 12:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi81-00087j-MM; Thu, 23 Oct 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACi7x-00086p-Mv for simple@optimus.ietf.org; Thu, 23 Oct 2003 12:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03764 for ; Thu, 23 Oct 2003 12:15:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACi7w-0003qa-00 for simple@ietf.org; Thu, 23 Oct 2003 12:15:56 -0400 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1ACi7u-0003qM-00 for simple@ietf.org; Thu, 23 Oct 2003 12:15:55 -0400 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Thu, 23 Oct 2003 21:50:36 +0530 Delivered-To: ipgen-india.com-sunku@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 3969 invoked by uid 7010); Thu Oct 23 21:38:59 2003 Received: (sifymail 3967 invoked by uid 7010); 23 Oct 2003 21:38:59 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 23 Oct 2003 21:38:59 +0530 Received: (sifymail 5854 invoked by uid 7005); 23 Oct 2003 21:38:59 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 23 Oct 2003 21:38:59 +0530 Received: (sifymail 5849 invoked by uid 7005); 23 Oct 2003 21:38:58 +0530 Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73) by 202.144.76.19 with SMTP; 23 Oct 2003 21:38:58 +0530 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1ACi6A-000082-00; Thu, 23 Oct 2003 12:14:06 -0400 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NGDvLZ029396 for ; Thu, 23 Oct 2003 12:13:58 -0400 (EDT) Received: from localhost.cisco.com (localhost.localdomain [127.0.0.1]) id h9NGDBd09030; Thu, 23 Oct 2003 11:13:11 -0500 From: Robert Sparks To: simple@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1066925585.11527.12.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip-implementors] Registration is now open for SIPIt 14 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 11:13:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIPIt 14 will take place February 8-13 in Cannes, France. The event will be hosted by by ETSI. More details and registration are available at http://www.etsi.org/plugtests/SIPIT14.htm >From Philippe Cousin at ETSI Plugtests: ETSI is happy to host the SIPit event again and to provide its free support to the SIP community. Sponsors are welcome either to support the global event or for the social event. Should your company be interested to helping sponser this nice event, please contact philippe.cousin@etsi.org RjS _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 23 14:02:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09542; Thu, 23 Oct 2003 14:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjmk-0005e5-00; Thu, 23 Oct 2003 14:02:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjmk-0005e2-00; Thu, 23 Oct 2003 14:02:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjmb-0003tS-SC; Thu, 23 Oct 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjlg-0003hl-KX for simple@optimus.ietf.org; Thu, 23 Oct 2003 14:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09448; Thu, 23 Oct 2003 14:00:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjle-0005dC-00; Thu, 23 Oct 2003 14:01:02 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACjld-0005cv-00; Thu, 23 Oct 2003 14:01:01 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9NI0gF8055971; Thu, 23 Oct 2003 13:00:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F981735.8050605@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, "'sipping@ietf.org'" , "'xcon@ietf.org'" , simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Softarmor Site Down Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 13:00:21 -0500 Content-Transfer-Encoding: 7bit Dean asked me to forward this on to the various lists: Softarmor.com is down due to a hardware failure. Dean is rushing to fix the problem as I write this. This will affect HTTP and email. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 23 14:02:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09603 for ; Thu, 23 Oct 2003 14:02:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjmo-0003zL-3k for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 14:02:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NI2EB3015325 for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 14:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjmn-0003yy-Tx for simple-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 14:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09542; Thu, 23 Oct 2003 14:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjmk-0005e5-00; Thu, 23 Oct 2003 14:02:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjmk-0005e2-00; Thu, 23 Oct 2003 14:02:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjmb-0003tS-SC; Thu, 23 Oct 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjlg-0003hl-KX for simple@optimus.ietf.org; Thu, 23 Oct 2003 14:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09448; Thu, 23 Oct 2003 14:00:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjle-0005dC-00; Thu, 23 Oct 2003 14:01:02 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACjld-0005cv-00; Thu, 23 Oct 2003 14:01:01 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9NI0gF8055971; Thu, 23 Oct 2003 13:00:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F981735.8050605@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, "'sipping@ietf.org'" , "'xcon@ietf.org'" , simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Softarmor Site Down Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 13:00:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dean asked me to forward this on to the various lists: Softarmor.com is down due to a hardware failure. Dean is rushing to fix the problem as I write this. This will affect HTTP and email. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 23 14:03:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09751; Thu, 23 Oct 2003 14:03:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjoa-0005h7-00; Thu, 23 Oct 2003 14:04:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjoa-0005h4-00; Thu, 23 Oct 2003 14:04:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjoX-0004aF-DI; Thu, 23 Oct 2003 14:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjns-0004TB-IB for simple@optimus.ietf.org; Thu, 23 Oct 2003 14:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09674 for ; Thu, 23 Oct 2003 14:03:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjnq-0005ff-00 for simple@ietf.org; Thu, 23 Oct 2003 14:03:18 -0400 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1ACjno-0005fV-00 for simple@ietf.org; Thu, 23 Oct 2003 14:03:17 -0400 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Thu, 23 Oct 2003 23:38:59 +0530 Delivered-To: ipgen-india.com-jijo@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 20635 invoked by uid 7010); Thu Oct 23 23:27:10 2003 Received: (sifymail 20633 invoked by uid 7010); 23 Oct 2003 23:27:10 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 23 Oct 2003 23:27:10 +0530 Received: (sifymail 22939 invoked by uid 7005); 23 Oct 2003 23:27:11 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 23 Oct 2003 23:27:11 +0530 Received: (sifymail 22929 invoked by uid 7005); 23 Oct 2003 23:27:10 +0530 Received: from 132.151.6.22 (HELO optimus.ietf.org) (132.151.6.22) by 202.144.76.19 with SMTP; 23 Oct 2003 23:27:10 +0530 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjmd-0003tq-Qk; Thu, 23 Oct 2003 14:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjlg-0003hl-Uu for sip@optimus.ietf.org; Thu, 23 Oct 2003 14:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09448; Thu, 23 Oct 2003 14:00:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjle-0005dC-00; Thu, 23 Oct 2003 14:01:02 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ACjld-0005cv-00; Thu, 23 Oct 2003 14:01:01 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h9NI0gF8055971; Thu, 23 Oct 2003 13:00:51 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F981735.8050605@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, "'sipping@ietf.org'" , "'xcon@ietf.org'" , simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip] Softarmor Site Down Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 13:00:21 -0500 Content-Transfer-Encoding: 7bit Dean asked me to forward this on to the various lists: Softarmor.com is down due to a hardware failure. Dean is rushing to fix the problem as I write this. This will affect HTTP and email. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 23 15:12:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13816; Thu, 23 Oct 2003 15:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACktM-0006ia-00; Thu, 23 Oct 2003 15:13:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACktM-0006iW-00; Thu, 23 Oct 2003 15:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACktK-0008D7-Do; Thu, 23 Oct 2003 15:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkso-0008A5-Mh for simple@optimus.ietf.org; Thu, 23 Oct 2003 15:12:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13739; Thu, 23 Oct 2003 15:12:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACksm-0006iC-00; Thu, 23 Oct 2003 15:12:28 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ACksm-0006hU-00; Thu, 23 Oct 2003 15:12:28 -0400 Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9NJBew6001569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Oct 2003 14:11:40 -0500 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9NJBe6Q001567; Thu, 23 Oct 2003 14:11:40 -0500 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f From: Dean Willis To: Ben Campbell Cc: sip@ietf.org, "'sipping@ietf.org'" , "'xcon@ietf.org'" , simple@ietf.org In-Reply-To: <3F981735.8050605@dynamicsoft.com> References: <3F981735.8050605@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066936299.1538.2.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] Softarmor Site Down Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 14:11:39 -0500 Content-Transfer-Encoding: 7bit OK, we seem to be back up. Apparently, power supplies have an MTBF of exactly 1 day longer than their warranty, with a very narrow standard deviation around that mean. The new one has 3 fans -- I don't know if that means it will last three times as long, or is three times more likely to fail. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 23 15:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13935 for ; Thu, 23 Oct 2003 15:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACktP-0008IJ-0p for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 15:13:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NJD6T1031879 for simple-archive@odin.ietf.org; Thu, 23 Oct 2003 15:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACktO-0008I6-RX for simple-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 15:13:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13816; Thu, 23 Oct 2003 15:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACktM-0006ia-00; Thu, 23 Oct 2003 15:13:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACktM-0006iW-00; Thu, 23 Oct 2003 15:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACktK-0008D7-Do; Thu, 23 Oct 2003 15:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkso-0008A5-Mh for simple@optimus.ietf.org; Thu, 23 Oct 2003 15:12:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13739; Thu, 23 Oct 2003 15:12:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACksm-0006iC-00; Thu, 23 Oct 2003 15:12:28 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ACksm-0006hU-00; Thu, 23 Oct 2003 15:12:28 -0400 Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9NJBew6001569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Oct 2003 14:11:40 -0500 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9NJBe6Q001567; Thu, 23 Oct 2003 14:11:40 -0500 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f From: Dean Willis To: Ben Campbell Cc: sip@ietf.org, "'sipping@ietf.org'" , "'xcon@ietf.org'" , simple@ietf.org In-Reply-To: <3F981735.8050605@dynamicsoft.com> References: <3F981735.8050605@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066936299.1538.2.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] Softarmor Site Down Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 14:11:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, we seem to be back up. Apparently, power supplies have an MTBF of exactly 1 day longer than their warranty, with a very narrow standard deviation around that mean. The new one has 3 fans -- I don't know if that means it will last three times as long, or is three times more likely to fail. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 23 15:14:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14188; Thu, 23 Oct 2003 15:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACkvI-0006mh-00; Thu, 23 Oct 2003 15:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACkvI-0006md-00; Thu, 23 Oct 2003 15:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkvH-0000LJ-BZ; Thu, 23 Oct 2003 15:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkuQ-0000CX-Bt for simple@optimus.ietf.org; Thu, 23 Oct 2003 15:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14043 for ; Thu, 23 Oct 2003 15:14:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACkuP-0006kD-00 for simple@ietf.org; Thu, 23 Oct 2003 15:14:09 -0400 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1ACkuM-0006jr-00 for simple@ietf.org; Thu, 23 Oct 2003 15:14:06 -0400 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Fri, 24 Oct 2003 00:49:48 +0530 Delivered-To: ipgen-india.com-jijo@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 32480 invoked by uid 7010); Fri Oct 24 00:37:59 2003 Received: (sifymail 32474 invoked by uid 7010); 24 Oct 2003 00:37:59 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 24 Oct 2003 00:37:59 +0530 Received: (sifymail 1328 invoked by uid 7005); 24 Oct 2003 00:37:59 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 24 Oct 2003 00:37:59 +0530 Received: (sifymail 1317 invoked by uid 7005); 24 Oct 2003 00:37:55 +0530 Received: from 132.151.6.22 (HELO optimus.ietf.org) (132.151.6.22) by 202.144.76.19 with SMTP; 24 Oct 2003 00:37:55 +0530 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACktI-0008CM-5n; Thu, 23 Oct 2003 15:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkso-0008A5-AJ for sip@optimus.ietf.org; Thu, 23 Oct 2003 15:12:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13739; Thu, 23 Oct 2003 15:12:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACksm-0006iC-00; Thu, 23 Oct 2003 15:12:28 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ACksm-0006hU-00; Thu, 23 Oct 2003 15:12:28 -0400 Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9NJBew6001569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Oct 2003 14:11:40 -0500 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9NJBe6Q001567; Thu, 23 Oct 2003 14:11:40 -0500 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f From: Dean Willis To: Ben Campbell Cc: sip@ietf.org, "'sipping@ietf.org'" , "'xcon@ietf.org'" , simple@ietf.org In-Reply-To: <3F981735.8050605@dynamicsoft.com> References: <3F981735.8050605@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066936299.1538.2.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] Softarmor Site Down Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 14:11:39 -0500 Content-Transfer-Encoding: 7bit OK, we seem to be back up. Apparently, power supplies have an MTBF of exactly 1 day longer than their warranty, with a very narrow standard deviation around that mean. The new one has 3 fans -- I don't know if that means it will last three times as long, or is three times more likely to fail. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 27 09:20:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14869; Mon, 27 Oct 2003 09:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8EH-0005ZB-00; Mon, 27 Oct 2003 09:20:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE8EH-0005Z6-00; Mon, 27 Oct 2003 09:20:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8E2-0006ds-Sp; Mon, 27 Oct 2003 09:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8D2-0006Gp-VH for simple@optimus.ietf.org; Mon, 27 Oct 2003 09:19:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14589; Mon, 27 Oct 2003 09:18:52 -0500 (EST) Message-Id: <200310271418.JAA14589@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Oct 2003 09:18:52 -0500 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell Filename : draft-ietf-simple-message-sessions-02.txt Pages : 57 Date : 2003-10-24 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the SDP offer/answer model carried by a signaling protocol such as SIP. MSRP supports end-to-end Instant Message Sessions, as well as sessions traversing one or two relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24161041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24161041.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Oct 27 17:15:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20508; Mon, 27 Oct 2003 17:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEFeH-0007O9-00; Mon, 27 Oct 2003 17:15:41 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEFeH-0007L0-00; Mon, 27 Oct 2003 17:15:41 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEFcA-0002J4-E7; Mon, 27 Oct 2003 17:13:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFaw-00086h-Tv; Mon, 27 Oct 2003 17:12:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFaC-0007qm-Vt for simple@optimus.ietf.org; Mon, 27 Oct 2003 17:11:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19605; Mon, 27 Oct 2003 17:11:16 -0500 (EST) Message-Id: <200310272211.RAA19605@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Oct 2003 17:11:15 -0500 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell Filename : draft-ietf-simple-message-sessions-02.txt Pages : 57 Date : 2003-10-24 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the SDP offer/answer model carried by a signaling protocol such as SIP. MSRP supports end-to-end Instant Message Sessions, as well as sessions traversing one or two relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171600.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Oct 27 17:16:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20801 for ; Mon, 27 Oct 2003 17:16:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFeL-0000WA-Ny for simple-archive@odin.ietf.org; Mon, 27 Oct 2003 17:15:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMFjsn001986 for simple-archive@odin.ietf.org; Mon, 27 Oct 2003 17:15:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFeL-0000Vt-7W for simple-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 17:15:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20508; Mon, 27 Oct 2003 17:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEFeH-0007O9-00; Mon, 27 Oct 2003 17:15:41 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEFeH-0007L0-00; Mon, 27 Oct 2003 17:15:41 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEFcA-0002J4-E7; Mon, 27 Oct 2003 17:13:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFaw-00086h-Tv; Mon, 27 Oct 2003 17:12:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFaC-0007qm-Vt for simple@optimus.ietf.org; Mon, 27 Oct 2003 17:11:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19605; Mon, 27 Oct 2003 17:11:16 -0500 (EST) Message-Id: <200310272211.RAA19605@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Oct 2003 17:11:15 -0500 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell Filename : draft-ietf-simple-message-sessions-02.txt Pages : 57 Date : 2003-10-24 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the SDP offer/answer model carried by a signaling protocol such as SIP. MSRP supports end-to-end Instant Message Sessions, as well as sessions traversing one or two relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171600.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 28 10:38:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00691; Tue, 28 Oct 2003 10:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVw0-000650-00; Tue, 28 Oct 2003 10:39:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEVw0-00064v-00; Tue, 28 Oct 2003 10:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVvw-0004tO-Rl; Tue, 28 Oct 2003 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVv4-0004iu-BX for simple@optimus.ietf.org; Tue, 28 Oct 2003 10:38:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00617 for ; Tue, 28 Oct 2003 10:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVv1-00063s-00 for simple@ietf.org; Tue, 28 Oct 2003 10:38:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEVv1-00063Q-00 for simple@ietf.org; Tue, 28 Oct 2003 10:38:03 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2003 07:37:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9SFbUN0026442 for ; Tue, 28 Oct 2003 10:37:30 -0500 (EST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADN09685; Tue, 28 Oct 2003 10:37:29 -0500 (EST) Message-ID: <3F9E8D39.4030306@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Oct 2003 10:37:29 -0500 Content-Transfer-Encoding: 7bit I see that this revision has tried to align the format of the new elements with the other elements in PIDF and RPIDS. Stylistically that is good. But, in the process, something important has been lost. In draft-ietf-sip-callee-caps-01 there is the possibility of using both base-tags defined explicitly in that document, and other-tags. But prescaps only represents the base-tags. I think it is important to provide a representation for those as well. Additionally, the xml representations of the values for base-tags does not cover the range of possibilities defined in callee-caps. In spite of this (or perhaps because of it) there is a nice simplicity to the elements now defined in the document. To fix the limitations, I suggest that one other element be defined: . Unlike the base tags where we can bake in the particular value representation that is permitted, for we can't know which specific value representation is appropriate, and so must support all the possibilities. I can see a few ways to do this: 1) use what was proposed in draft-lonnfors-simple-prescaps-ext-01. pros: we already have a proposal for it cons: it has a bug - can't distinguish between token and string values; its kind of wordy 2) use the literal string representation used in contact headers in draft-ietf-sip-callee-caps-01. pros: the mapping is straightforward; it covers all cases; easy to use the same matching algorithm with both presence data and registration data cons: it isn't very user friendly if ever presented directly to a user; it isn't a very convenient representation for code that doesn't need to implement the matching alg. 3) convert the value to rfc 2533 format, and embed that in the element. pros: the mapping is well defined and covers all the cases; convenient for someone implementing the matching alg by literally using 2533. cons: truly an arcane representation; very inconvenient for anyone not implementing 2533 literally; doesn't lend itself to representing each "other-tag" and value separately. I conclude that (2) is probably the best overall. (Other opinions welcome.) The following is the example from prescaps, extended in this way: open true true true INVITE,MESSAGE, ACK,BYE,CANCEL #=5,!#<=10 !en !red,blue TRUE sip:someone@examaple.com This is equivalent to the following contact: Contact: sip:someone@examaple.com; video;audio;mobile; methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; +sip.priority="#=5,!#<=10" +language="!en"; +g.sip!foo@tags.example.com="!red,blue"; +g.sip!bar@tags.example.com; or equivalently: Contact: sip:someone@examaple.com; video;audio;mobile; methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; priority="#=5,!#<=10"; language="!en" +g.sip!foo@tags.example.com="!red,blue"; +g.sip!bar@tags.example.com Note that not only does this address other tags, it also addresses values for base-tags that are more complex than the simple representation can handle. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 28 10:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00725 for ; Tue, 28 Oct 2003 10:39:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVw4-0004vP-3a for simple-archive@odin.ietf.org; Tue, 28 Oct 2003 10:39:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SFd8qE018927 for simple-archive@odin.ietf.org; Tue, 28 Oct 2003 10:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVw4-0004vC-0P for simple-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 10:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00691; Tue, 28 Oct 2003 10:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVw0-000650-00; Tue, 28 Oct 2003 10:39:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEVw0-00064v-00; Tue, 28 Oct 2003 10:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVvw-0004tO-Rl; Tue, 28 Oct 2003 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVv4-0004iu-BX for simple@optimus.ietf.org; Tue, 28 Oct 2003 10:38:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00617 for ; Tue, 28 Oct 2003 10:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVv1-00063s-00 for simple@ietf.org; Tue, 28 Oct 2003 10:38:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEVv1-00063Q-00 for simple@ietf.org; Tue, 28 Oct 2003 10:38:03 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2003 07:37:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9SFbUN0026442 for ; Tue, 28 Oct 2003 10:37:30 -0500 (EST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADN09685; Tue, 28 Oct 2003 10:37:29 -0500 (EST) Message-ID: <3F9E8D39.4030306@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Oct 2003 10:37:29 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I see that this revision has tried to align the format of the new elements with the other elements in PIDF and RPIDS. Stylistically that is good. But, in the process, something important has been lost. In draft-ietf-sip-callee-caps-01 there is the possibility of using both base-tags defined explicitly in that document, and other-tags. But prescaps only represents the base-tags. I think it is important to provide a representation for those as well. Additionally, the xml representations of the values for base-tags does not cover the range of possibilities defined in callee-caps. In spite of this (or perhaps because of it) there is a nice simplicity to the elements now defined in the document. To fix the limitations, I suggest that one other element be defined: . Unlike the base tags where we can bake in the particular value representation that is permitted, for we can't know which specific value representation is appropriate, and so must support all the possibilities. I can see a few ways to do this: 1) use what was proposed in draft-lonnfors-simple-prescaps-ext-01. pros: we already have a proposal for it cons: it has a bug - can't distinguish between token and string values; its kind of wordy 2) use the literal string representation used in contact headers in draft-ietf-sip-callee-caps-01. pros: the mapping is straightforward; it covers all cases; easy to use the same matching algorithm with both presence data and registration data cons: it isn't very user friendly if ever presented directly to a user; it isn't a very convenient representation for code that doesn't need to implement the matching alg. 3) convert the value to rfc 2533 format, and embed that in the element. pros: the mapping is well defined and covers all the cases; convenient for someone implementing the matching alg by literally using 2533. cons: truly an arcane representation; very inconvenient for anyone not implementing 2533 literally; doesn't lend itself to representing each "other-tag" and value separately. I conclude that (2) is probably the best overall. (Other opinions welcome.) The following is the example from prescaps, extended in this way: open true true true INVITE,MESSAGE, ACK,BYE,CANCEL #=5,!#<=10 !en !red,blue TRUE sip:someone@examaple.com This is equivalent to the following contact: Contact: sip:someone@examaple.com; video;audio;mobile; methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; +sip.priority="#=5,!#<=10" +language="!en"; +g.sip!foo@tags.example.com="!red,blue"; +g.sip!bar@tags.example.com; or equivalently: Contact: sip:someone@examaple.com; video;audio;mobile; methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; priority="#=5,!#<=10"; language="!en" +g.sip!foo@tags.example.com="!red,blue"; +g.sip!bar@tags.example.com Note that not only does this address other tags, it also addresses values for base-tags that are more complex than the simple representation can handle. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Oct 28 12:53:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12717; Tue, 28 Oct 2003 12:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEY2c-0002sW-00; Tue, 28 Oct 2003 12:54:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEY2b-0002sT-00; Tue, 28 Oct 2003 12:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY2b-0002YC-5M; Tue, 28 Oct 2003 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY25-0002QH-M9 for simple@optimus.ietf.org; Tue, 28 Oct 2003 12:53:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12605 for ; Tue, 28 Oct 2003 12:53:16 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEY23-0002qT-00 for simple@ietf.org; Tue, 28 Oct 2003 12:53:27 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AEY22-0002qN-00 for simple@ietf.org; Tue, 28 Oct 2003 12:53:27 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9SHrPI02150 for ; Tue, 28 Oct 2003 19:53:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 28 Oct 2003 19:53:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 28 Oct 2003 19:53:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797342@esebe019.ntc.nokia.com> Thread-Topic: Event Notification Filtering Drafts Thread-Index: AcOdfGGe8Oo83+jRRs+E8kC0/L/fag== To: X-OriginalArrivalTime: 28 Oct 2003 17:53:25.0159 (UTC) FILETIME=[628F9B70:01C39D7C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Event Notification Filtering Drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Oct 2003 19:53:24 +0200 Content-Transfer-Encoding: quoted-printable An update to the Event Notification Filtering solutions is now = available. The XML format is defined in: http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-format-= 01.txt The functionality draft is defined in: http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-0= 1.txt One major change in the format draft is that we removed the xpath = expression and defined a trimmed down version suitable for the filtering = solution needs. The functionality draft changes were minor. The requirements drafts can be found behind the following links: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02= .txt http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-0= 0.txt There has been no update to the requirements document due to lack of = comments. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Oct 28 12:54:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12789 for ; Tue, 28 Oct 2003 12:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY2e-0002aL-Kd for simple-archive@odin.ietf.org; Tue, 28 Oct 2003 12:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SHs4OG009915 for simple-archive@odin.ietf.org; Tue, 28 Oct 2003 12:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY2e-0002Z1-CP for simple-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 12:54:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12717; Tue, 28 Oct 2003 12:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEY2c-0002sW-00; Tue, 28 Oct 2003 12:54:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEY2b-0002sT-00; Tue, 28 Oct 2003 12:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY2b-0002YC-5M; Tue, 28 Oct 2003 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY25-0002QH-M9 for simple@optimus.ietf.org; Tue, 28 Oct 2003 12:53:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12605 for ; Tue, 28 Oct 2003 12:53:16 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEY23-0002qT-00 for simple@ietf.org; Tue, 28 Oct 2003 12:53:27 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AEY22-0002qN-00 for simple@ietf.org; Tue, 28 Oct 2003 12:53:27 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9SHrPI02150 for ; Tue, 28 Oct 2003 19:53:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 28 Oct 2003 19:53:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 28 Oct 2003 19:53:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797342@esebe019.ntc.nokia.com> Thread-Topic: Event Notification Filtering Drafts Thread-Index: AcOdfGGe8Oo83+jRRs+E8kC0/L/fag== To: X-OriginalArrivalTime: 28 Oct 2003 17:53:25.0159 (UTC) FILETIME=[628F9B70:01C39D7C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Event Notification Filtering Drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Oct 2003 19:53:24 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable An update to the Event Notification Filtering solutions is now = available. The XML format is defined in: http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-format-= 01.txt The functionality draft is defined in: http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-0= 1.txt One major change in the format draft is that we removed the xpath = expression and defined a trimmed down version suitable for the filtering = solution needs. The functionality draft changes were minor. The requirements drafts can be found behind the following links: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02= .txt http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-0= 0.txt There has been no update to the requirements document due to lack of = comments. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 29 10:23:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12670; Wed, 29 Oct 2003 10:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsAu-0002VS-00; Wed, 29 Oct 2003 10:23:56 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsAs-0002UP-00; Wed, 29 Oct 2003 10:23:54 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEsAT-0007fA-KK; Wed, 29 Oct 2003 10:23:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsA2-0003oF-28; Wed, 29 Oct 2003 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs9t-0003i5-LK for simple@optimus.ietf.org; Wed, 29 Oct 2003 10:22:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12586 for ; Wed, 29 Oct 2003 10:22:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEs9r-0002Sw-00 for simple@ietf.org; Wed, 29 Oct 2003 10:22:51 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1AEs9o-0002Sn-00 for simple@ietf.org; Wed, 29 Oct 2003 10:22:50 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Wed, 29 Oct 2003 20:58:31 +0530 Delivered-To: ipgen-india.com-sunku@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 16972 invoked by uid 7010); Wed Oct 29 20:45:44 2003 Received: (sifymail 16970 invoked by uid 7010); 29 Oct 2003 20:45:44 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 29 Oct 2003 20:45:44 +0530 Received: (sifymail 22254 invoked by uid 7005); 29 Oct 2003 20:45:44 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 29 Oct 2003 20:45:44 +0530 Received: (sifymail 22248 invoked by uid 7005); 29 Oct 2003 20:45:44 +0530 Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73) by 202.144.76.19 with SMTP; 29 Oct 2003 20:45:44 +0530 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1AEs8h-0003wV-03; Wed, 29 Oct 2003 10:21:39 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9TFLTLZ017021 for ; Wed, 29 Oct 2003 10:21:29 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) id h9TFKqd07162; Wed, 29 Oct 2003 09:20:52 -0600 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu, sip@ietf.org In-Reply-To: <1063221430.882.190.camel@RjS.localdomain> References: <1063221430.882.190.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1067440852.1005.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip-implementors] Re: SIMPLEt 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 09:20:53 -0600 Content-Transfer-Encoding: 7bit SIMPLEt 2 registration closes in about two weeks. If you have not already registered, please do so now. If you plan to register, but for some reason have to wait until the last minute, please send me a note letting me know you are planning to attend. Registration information can be found at http://simplet.jasomi.com Thanks! RjS _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 29 10:23:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12716; Wed, 29 Oct 2003 10:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsAy-0002Wy-00; Wed, 29 Oct 2003 10:24:00 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsAv-0002UI-00; Wed, 29 Oct 2003 10:23:57 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEs9F-0007d1-ON; Wed, 29 Oct 2003 10:22:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs95-0003Q3-W8; Wed, 29 Oct 2003 10:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs8U-0003KR-Pj for simple@optimus.ietf.org; Wed, 29 Oct 2003 10:21:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12546; Wed, 29 Oct 2003 10:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEs8S-0002Ru-00; Wed, 29 Oct 2003 10:21:24 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AEs8R-0002Rh-00; Wed, 29 Oct 2003 10:21:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9TFKqd07162; Wed, 29 Oct 2003 09:20:52 -0600 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu, sip@ietf.org In-Reply-To: <1063221430.882.190.camel@RjS.localdomain> References: <1063221430.882.190.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1067440852.1005.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: SIMPLEt 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 09:20:53 -0600 Content-Transfer-Encoding: 7bit SIMPLEt 2 registration closes in about two weeks. If you have not already registered, please do so now. If you plan to register, but for some reason have to wait until the last minute, please send me a note letting me know you are planning to attend. Registration information can be found at http://simplet.jasomi.com Thanks! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 29 10:24:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12860 for ; Wed, 29 Oct 2003 10:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsAz-0004A9-Ro for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 10:24:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFO1Qo015975 for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 10:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsAy-00049P-Bk for simple-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:24:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12670; Wed, 29 Oct 2003 10:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsAu-0002VS-00; Wed, 29 Oct 2003 10:23:56 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsAs-0002UP-00; Wed, 29 Oct 2003 10:23:54 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEsAT-0007fA-KK; Wed, 29 Oct 2003 10:23:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsA2-0003oF-28; Wed, 29 Oct 2003 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs9t-0003i5-LK for simple@optimus.ietf.org; Wed, 29 Oct 2003 10:22:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12586 for ; Wed, 29 Oct 2003 10:22:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEs9r-0002Sw-00 for simple@ietf.org; Wed, 29 Oct 2003 10:22:51 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1AEs9o-0002Sn-00 for simple@ietf.org; Wed, 29 Oct 2003 10:22:50 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Wed, 29 Oct 2003 20:58:31 +0530 Delivered-To: ipgen-india.com-sunku@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 16972 invoked by uid 7010); Wed Oct 29 20:45:44 2003 Received: (sifymail 16970 invoked by uid 7010); 29 Oct 2003 20:45:44 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 29 Oct 2003 20:45:44 +0530 Received: (sifymail 22254 invoked by uid 7005); 29 Oct 2003 20:45:44 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 29 Oct 2003 20:45:44 +0530 Received: (sifymail 22248 invoked by uid 7005); 29 Oct 2003 20:45:44 +0530 Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73) by 202.144.76.19 with SMTP; 29 Oct 2003 20:45:44 +0530 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1AEs8h-0003wV-03; Wed, 29 Oct 2003 10:21:39 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9TFLTLZ017021 for ; Wed, 29 Oct 2003 10:21:29 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) id h9TFKqd07162; Wed, 29 Oct 2003 09:20:52 -0600 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu, sip@ietf.org In-Reply-To: <1063221430.882.190.camel@RjS.localdomain> References: <1063221430.882.190.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1067440852.1005.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip-implementors] Re: SIMPLEt 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 09:20:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIMPLEt 2 registration closes in about two weeks. If you have not already registered, please do so now. If you plan to register, but for some reason have to wait until the last minute, please send me a note letting me know you are planning to attend. Registration information can be found at http://simplet.jasomi.com Thanks! RjS _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 29 10:24:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12875 for ; Wed, 29 Oct 2003 10:24:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsB2-0004B7-6T for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 10:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFO4jp016055 for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 10:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsB2-0004As-1q for simple-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:24:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12716; Wed, 29 Oct 2003 10:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsAy-0002Wy-00; Wed, 29 Oct 2003 10:24:00 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsAv-0002UI-00; Wed, 29 Oct 2003 10:23:57 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEs9F-0007d1-ON; Wed, 29 Oct 2003 10:22:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs95-0003Q3-W8; Wed, 29 Oct 2003 10:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs8U-0003KR-Pj for simple@optimus.ietf.org; Wed, 29 Oct 2003 10:21:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12546; Wed, 29 Oct 2003 10:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEs8S-0002Ru-00; Wed, 29 Oct 2003 10:21:24 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AEs8R-0002Rh-00; Wed, 29 Oct 2003 10:21:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9TFKqd07162; Wed, 29 Oct 2003 09:20:52 -0600 From: Robert Sparks To: simple@ietf.org, sip-implementors@cs.columbia.edu, sip@ietf.org In-Reply-To: <1063221430.882.190.camel@RjS.localdomain> References: <1063221430.882.190.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1067440852.1005.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: SIMPLEt 2 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 09:20:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIMPLEt 2 registration closes in about two weeks. If you have not already registered, please do so now. If you plan to register, but for some reason have to wait until the last minute, please send me a note letting me know you are planning to attend. Registration information can be found at http://simplet.jasomi.com Thanks! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 29 13:59:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26951; Wed, 29 Oct 2003 13:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvXu-0000Jx-00; Wed, 29 Oct 2003 13:59:54 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEvTp-0000BX-00; Wed, 29 Oct 2003 13:55:41 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEvJm-00071g-AD; Wed, 29 Oct 2003 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJW-00057Y-Sc; Wed, 29 Oct 2003 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJ7-00054v-RE for simple@optimus.ietf.org; Wed, 29 Oct 2003 13:44:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26321; Wed, 29 Oct 2003 13:44:26 -0500 (EST) Message-Id: <200310291844.NAA26321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 13:44:26 -0500 --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 : Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-auth-usage-01.txt Pages : 24 Date : 2003-10-29 This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-auth-usage-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-29140419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-auth-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29140419.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 29 13:59:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26960; Wed, 29 Oct 2003 13:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvXv-0000K2-00; Wed, 29 Oct 2003 13:59:55 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEvTo-0000BX-01; Wed, 29 Oct 2003 13:55:40 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEvJm-00071h-D5; Wed, 29 Oct 2003 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJX-00057g-Ic; Wed, 29 Oct 2003 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJF-00055W-VZ for simple@optimus.ietf.org; Wed, 29 Oct 2003 13:44:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26337; Wed, 29 Oct 2003 13:44:34 -0500 (EST) Message-Id: <200310291844.NAA26337@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 13:44:34 -0500 --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 : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-01.txt Pages : 29 Date : 2003-10-29 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-29140444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29140444.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Oct 29 13:59:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26975; Wed, 29 Oct 2003 13:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvXv-0000K7-00; Wed, 29 Oct 2003 13:59:55 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEvTo-0000BX-00; Wed, 29 Oct 2003 13:55:40 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEvJm-00071i-Es; Wed, 29 Oct 2003 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJW-00057N-8u; Wed, 29 Oct 2003 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvIc-00053V-JX for simple@optimus.ietf.org; Wed, 29 Oct 2003 13:44:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26277; Wed, 29 Oct 2003 13:43:55 -0500 (EST) Message-Id: <200310291843.NAA26277@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-list-usage-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 13:43:55 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-list-usage-01.txt Pages : 21 Date : 2003-10-29 This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating lists of presentities (also known as buddy lists or rosters). It does so by specifying an XML Schema that contains a list of presentities that a user is interested in watching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-list-usage-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-29140344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-list-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29140344.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 29 14:00:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27237 for ; Wed, 29 Oct 2003 14:00:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvXx-0006Jl-PW for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 13:59:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TIxvsi024285 for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 13:59:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvXx-0006Jc-Mi for simple-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 13:59:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26951; Wed, 29 Oct 2003 13:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvXu-0000Jx-00; Wed, 29 Oct 2003 13:59:54 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEvTp-0000BX-00; Wed, 29 Oct 2003 13:55:41 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEvJm-00071g-AD; Wed, 29 Oct 2003 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJW-00057Y-Sc; Wed, 29 Oct 2003 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJ7-00054v-RE for simple@optimus.ietf.org; Wed, 29 Oct 2003 13:44:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26321; Wed, 29 Oct 2003 13:44:26 -0500 (EST) Message-Id: <200310291844.NAA26321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 13:44:26 -0500 --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 : Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-auth-usage-01.txt Pages : 24 Date : 2003-10-29 This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-auth-usage-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-29140419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-auth-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29140419.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 29 14:00:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27249 for ; Wed, 29 Oct 2003 14:00:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvXy-0006K9-C5 for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 13:59:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TIxw1t024303 for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 13:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvXy-0006Ju-8m for simple-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 13:59:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26960; Wed, 29 Oct 2003 13:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvXv-0000K2-00; Wed, 29 Oct 2003 13:59:55 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEvTo-0000BX-01; Wed, 29 Oct 2003 13:55:40 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEvJm-00071h-D5; Wed, 29 Oct 2003 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJX-00057g-Ic; Wed, 29 Oct 2003 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJF-00055W-VZ for simple@optimus.ietf.org; Wed, 29 Oct 2003 13:44:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26337; Wed, 29 Oct 2003 13:44:34 -0500 (EST) Message-Id: <200310291844.NAA26337@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 13:44:34 -0500 --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 : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-01.txt Pages : 29 Date : 2003-10-29 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-29140444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29140444.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Oct 29 14:00:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27266 for ; Wed, 29 Oct 2003 14:00:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvXy-0006KR-VE for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 13:59:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TIxwlG024321 for simple-archive@odin.ietf.org; Wed, 29 Oct 2003 13:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvXy-0006KC-S4 for simple-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 13:59:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26975; Wed, 29 Oct 2003 13:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvXv-0000K7-00; Wed, 29 Oct 2003 13:59:55 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEvTo-0000BX-00; Wed, 29 Oct 2003 13:55:40 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEvJm-00071i-Es; Wed, 29 Oct 2003 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvJW-00057N-8u; Wed, 29 Oct 2003 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvIc-00053V-JX for simple@optimus.ietf.org; Wed, 29 Oct 2003 13:44:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26277; Wed, 29 Oct 2003 13:43:55 -0500 (EST) Message-Id: <200310291843.NAA26277@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-list-usage-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Oct 2003 13:43:55 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-list-usage-01.txt Pages : 21 Date : 2003-10-29 This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating lists of presentities (also known as buddy lists or rosters). It does so by specifying an XML Schema that contains a list of presentities that a user is interested in watching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-list-usage-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-29140344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-list-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29140344.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 10:01:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24359; Thu, 30 Oct 2003 10:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEJJ-0004W1-00; Thu, 30 Oct 2003 10:02:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEJJ-0004Vy-00; Thu, 30 Oct 2003 10:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEJF-00065o-Fg; Thu, 30 Oct 2003 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEIe-00062U-4o for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:01:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24311 for ; Thu, 30 Oct 2003 10:01:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEIc-0004VF-00 for simple@ietf.org; Thu, 30 Oct 2003 10:01:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEIb-0004Uz-00 for simple@ietf.org; Thu, 30 Oct 2003 10:01:21 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UF0lca008519 for ; Thu, 30 Oct 2003 10:00:48 -0500 (EST) Message-ID: <3FA1279D.7060902@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Changes to XCAP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:00:45 -0500 Content-Transfer-Encoding: 7bit Folks, As you may have noticed, I (finally) submitted a rev of the xcap spec. The changes are based on discussions on the list since the last IETF. To summarize the changes: * aligned this with a pure http usage. This means there is no POST, only PUT, and the spec tries to be clear that its all about how to map URIs to XML resources * Came up with a concrete rule for how a server inserts an element or attribute. The rule is simple: - if the r-uri evaluates to an element or attribute that exists in the document, its replaced by the content of the request (which must contain an element or attribute, respectively) - if the r-uri doesnt match anything that exists in the document, this is an insertion. The content of the request is inserted in such a way that, after insertion, the r-uri evaluates to the element or attribute which was just inserted This is semantically equivalent to how a regular file gets inserted with PUT, but has clearer meaning in the context of XML components. Most importantly, this rule gives you the ability to control how insertion is done. FOr example: PUT http://?xml-root/foo/bar[2] this will be inserted as the SECOND bar in the doc if there is only one bar * I added a grammar for AUIDs * No longer using xpath directly. Instead, there is a section in the doc which defines syntax and semantics for a subset of the xpath functionality. Expressiosn compliant to this syntax are a proper xpath expression, though. * vendor specific AUIDs are represented using the java-style naming convention of reverse domains. * As suggested by Scott, I am using Etags now, not modification times. * Explicitly mention that batching isnt provided. Instead, you have to design your schema so that you can maintain useful and meaningful documents after each single read/modify/write operation * Specify that servers need to be aware of all namespaces used in documents they manage. * Clarified a bit on how authorization is done - that application usages can specify that their authorization is handled by an existing or even a future application usage * Updated the examples * Eliminated the open issue on error content. No new error reporting is provided. If the client tries to PUT or DELETE and this results in an invalid document, the server returns 409, thats it. No more detail than that. My reasoning here is that, in most cases, an automata in the client would not be able to recover from such an error in any case... I am pretty happy with where this landed up. THere is only really one explicitly mentioned open issue, which is MIME types. The question there is, what do we say (if anythng) about the specific MIME types that need to be present in request and resposnes? i.e., application/xml, text/xml, text/plain, or the mime type specific to the applicatoin usage? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 10:02:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24376 for ; Thu, 30 Oct 2003 10:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEJN-00068q-0x for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:02:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UF29JS023608 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:02:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEJM-00068h-SM for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 10:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24359; Thu, 30 Oct 2003 10:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEJJ-0004W1-00; Thu, 30 Oct 2003 10:02:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEJJ-0004Vy-00; Thu, 30 Oct 2003 10:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEJF-00065o-Fg; Thu, 30 Oct 2003 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEIe-00062U-4o for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:01:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24311 for ; Thu, 30 Oct 2003 10:01:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEIc-0004VF-00 for simple@ietf.org; Thu, 30 Oct 2003 10:01:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEIb-0004Uz-00 for simple@ietf.org; Thu, 30 Oct 2003 10:01:21 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UF0lca008519 for ; Thu, 30 Oct 2003 10:00:48 -0500 (EST) Message-ID: <3FA1279D.7060902@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Changes to XCAP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:00:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, As you may have noticed, I (finally) submitted a rev of the xcap spec. The changes are based on discussions on the list since the last IETF. To summarize the changes: * aligned this with a pure http usage. This means there is no POST, only PUT, and the spec tries to be clear that its all about how to map URIs to XML resources * Came up with a concrete rule for how a server inserts an element or attribute. The rule is simple: - if the r-uri evaluates to an element or attribute that exists in the document, its replaced by the content of the request (which must contain an element or attribute, respectively) - if the r-uri doesnt match anything that exists in the document, this is an insertion. The content of the request is inserted in such a way that, after insertion, the r-uri evaluates to the element or attribute which was just inserted This is semantically equivalent to how a regular file gets inserted with PUT, but has clearer meaning in the context of XML components. Most importantly, this rule gives you the ability to control how insertion is done. FOr example: PUT http://?xml-root/foo/bar[2] this will be inserted as the SECOND bar in the doc if there is only one bar * I added a grammar for AUIDs * No longer using xpath directly. Instead, there is a section in the doc which defines syntax and semantics for a subset of the xpath functionality. Expressiosn compliant to this syntax are a proper xpath expression, though. * vendor specific AUIDs are represented using the java-style naming convention of reverse domains. * As suggested by Scott, I am using Etags now, not modification times. * Explicitly mention that batching isnt provided. Instead, you have to design your schema so that you can maintain useful and meaningful documents after each single read/modify/write operation * Specify that servers need to be aware of all namespaces used in documents they manage. * Clarified a bit on how authorization is done - that application usages can specify that their authorization is handled by an existing or even a future application usage * Updated the examples * Eliminated the open issue on error content. No new error reporting is provided. If the client tries to PUT or DELETE and this results in an invalid document, the server returns 409, thats it. No more detail than that. My reasoning here is that, in most cases, an automata in the client would not be able to recover from such an error in any case... I am pretty happy with where this landed up. THere is only really one explicitly mentioned open issue, which is MIME types. The question there is, what do we say (if anythng) about the specific MIME types that need to be present in request and resposnes? i.e., application/xml, text/xml, text/plain, or the mime type specific to the applicatoin usage? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 10:18:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26274; Thu, 30 Oct 2003 10:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEZm-0004mC-00; Thu, 30 Oct 2003 10:19:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEZm-0004m9-00; Thu, 30 Oct 2003 10:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEZg-0007yV-QJ; Thu, 30 Oct 2003 10:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEZ1-0007wl-PI for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:18:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26201 for ; Thu, 30 Oct 2003 10:18:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEYz-0004lJ-00 for simple@ietf.org; Thu, 30 Oct 2003 10:18:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEYy-0004lD-00 for simple@ietf.org; Thu, 30 Oct 2003 10:18:16 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UFHica008529 for ; Thu, 30 Oct 2003 10:17:45 -0500 (EST) Message-ID: <3FA12B97.5080408@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Changes in xcap-auth Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:17:43 -0500 Content-Transfer-Encoding: 7bit Folks, As you may have noticed, I submitted a revision of the xcap-auth spec. There were many changes since the last rev. Mainly, I cut lots of stuff out in order to vastly simplify: * added an "except" clause to applies-to, so that you can make exceptions for specific users, domains, or lists. This allows, for example: example.com * accept-if permission exists still, but boolean expressions are removed. * Removed rule permissions (which specified state changes which would cause a notification to be sent) * Removed transformational permissions. I still think this capability is important, but per list discussion, we will tackle it by having a separate entity publish false presence information, and then use xcap-auth to select those tuples for distribution to certain watchers. * removed requested-namespace, requested-element, requested-tuple, duration accept-if conditions * show-tuple content permission now selects a tuple(s) by the RPID class attribute * removed show-values content permission * removed the compound permission AUID - can do it later * The show-element content permission selects elements based on their qualified name (i.e., rpid:placetype) in an XML document - no xpath expressions. * clarified that, for show-element and show-namespace, if a permission is not there, those elements in published tuples are discarded BEFORE the composition process. There are a few to-dos that I wasnt able to get around to. Besides that, I think this is much closer to done. There are still some open issues, which I will post notes on. There is also a big question around how/if the geopriv policy format aligns with this. The other main question is scope - is there anything else we can remove, or anything that is ESSENTIAL now which we should add? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 10:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26342 for ; Thu, 30 Oct 2003 10:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEZp-00081n-PI for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:19:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFJ9b9030853 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEZp-00081Y-LD for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 10:19:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26274; Thu, 30 Oct 2003 10:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEZm-0004mC-00; Thu, 30 Oct 2003 10:19:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEZm-0004m9-00; Thu, 30 Oct 2003 10:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEZg-0007yV-QJ; Thu, 30 Oct 2003 10:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEZ1-0007wl-PI for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:18:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26201 for ; Thu, 30 Oct 2003 10:18:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEYz-0004lJ-00 for simple@ietf.org; Thu, 30 Oct 2003 10:18:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEYy-0004lD-00 for simple@ietf.org; Thu, 30 Oct 2003 10:18:16 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UFHica008529 for ; Thu, 30 Oct 2003 10:17:45 -0500 (EST) Message-ID: <3FA12B97.5080408@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Changes in xcap-auth Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:17:43 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, As you may have noticed, I submitted a revision of the xcap-auth spec. There were many changes since the last rev. Mainly, I cut lots of stuff out in order to vastly simplify: * added an "except" clause to applies-to, so that you can make exceptions for specific users, domains, or lists. This allows, for example: example.com * accept-if permission exists still, but boolean expressions are removed. * Removed rule permissions (which specified state changes which would cause a notification to be sent) * Removed transformational permissions. I still think this capability is important, but per list discussion, we will tackle it by having a separate entity publish false presence information, and then use xcap-auth to select those tuples for distribution to certain watchers. * removed requested-namespace, requested-element, requested-tuple, duration accept-if conditions * show-tuple content permission now selects a tuple(s) by the RPID class attribute * removed show-values content permission * removed the compound permission AUID - can do it later * The show-element content permission selects elements based on their qualified name (i.e., rpid:placetype) in an XML document - no xpath expressions. * clarified that, for show-element and show-namespace, if a permission is not there, those elements in published tuples are discarded BEFORE the composition process. There are a few to-dos that I wasnt able to get around to. Besides that, I think this is much closer to done. There are still some open issues, which I will post notes on. There is also a big question around how/if the geopriv policy format aligns with this. The other main question is scope - is there anything else we can remove, or anything that is ESSENTIAL now which we should add? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 10:30:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26799; Thu, 30 Oct 2003 10:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFElK-0004xS-00; Thu, 30 Oct 2003 10:31:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFElK-0004xP-00; Thu, 30 Oct 2003 10:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFElI-0001J4-Ps; Thu, 30 Oct 2003 10:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEkY-0001Ef-7e for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26732 for ; Thu, 30 Oct 2003 10:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEkV-0004wv-00 for simple@ietf.org; Thu, 30 Oct 2003 10:30:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEkU-0004ug-00 for simple@ietf.org; Thu, 30 Oct 2003 10:30:11 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UFTcca008542 for ; Thu, 30 Oct 2003 10:29:39 -0500 (EST) Message-ID: <3FA12E60.2070702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Knowing which tuples to select Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:29:36 -0500 Content-Transfer-Encoding: 7bit Folks, As I mentioned in a previous note, per list discussion I removed transformational permissions from xcap-auth. Instead of havgin the xcap server apply the transformations, the idea proposed by Henning and others is to have a separate "application" in the network publish tuples for me that contain whatever information I wish to distribute. Indeed, the application itself might live in the endpoint as well. THere are still some open questions about achieving interoperability in such an environment, particularly if the application lives in the network: * how does the user configure the behavior of this application? I think this is out of scope; we are not going to try and provide standardized interfaces for this control - thats the whole idea. * assuming the user controls the application somehow, it will begin publishing tuples. How does the client know the RPID class of those tuples, so that it can control their distribution via xcap? I see only a few choices for the second issue: * ignore the problem - presumably the application will tell the user through some kind of UI which class to select * agree on a standardized naming convention for tuples published by such applications * treat this as a configuration problem. The device needs to be configured with RPID class corresponding to tuples published by applications. In that case, we might be able to place this data into xcap itself, so that it can be read by the client device. This would presumably be a separate application usage. I'm inclined to go for the third option. Thoughts? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 10:31:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26852 for ; Thu, 30 Oct 2003 10:31:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFElP-0001M1-Gn for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFV7H1005204 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:31:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFElP-0001Lr-DK for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 10:31:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26799; Thu, 30 Oct 2003 10:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFElK-0004xS-00; Thu, 30 Oct 2003 10:31:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFElK-0004xP-00; Thu, 30 Oct 2003 10:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFElI-0001J4-Ps; Thu, 30 Oct 2003 10:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEkY-0001Ef-7e for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26732 for ; Thu, 30 Oct 2003 10:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEkV-0004wv-00 for simple@ietf.org; Thu, 30 Oct 2003 10:30:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEkU-0004ug-00 for simple@ietf.org; Thu, 30 Oct 2003 10:30:11 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UFTcca008542 for ; Thu, 30 Oct 2003 10:29:39 -0500 (EST) Message-ID: <3FA12E60.2070702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Knowing which tuples to select Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:29:36 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, As I mentioned in a previous note, per list discussion I removed transformational permissions from xcap-auth. Instead of havgin the xcap server apply the transformations, the idea proposed by Henning and others is to have a separate "application" in the network publish tuples for me that contain whatever information I wish to distribute. Indeed, the application itself might live in the endpoint as well. THere are still some open questions about achieving interoperability in such an environment, particularly if the application lives in the network: * how does the user configure the behavior of this application? I think this is out of scope; we are not going to try and provide standardized interfaces for this control - thats the whole idea. * assuming the user controls the application somehow, it will begin publishing tuples. How does the client know the RPID class of those tuples, so that it can control their distribution via xcap? I see only a few choices for the second issue: * ignore the problem - presumably the application will tell the user through some kind of UI which class to select * agree on a standardized naming convention for tuples published by such applications * treat this as a configuration problem. The device needs to be configured with RPID class corresponding to tuples published by applications. In that case, we might be able to place this data into xcap itself, so that it can be read by the client device. This would presumably be a separate application usage. I'm inclined to go for the third option. Thoughts? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 10:32:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26915; Thu, 30 Oct 2003 10:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEnJ-0004zp-00; Thu, 30 Oct 2003 10:33:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEnI-0004zm-00; Thu, 30 Oct 2003 10:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEnF-0001Wc-JN; Thu, 30 Oct 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEn9-0001Vr-B6 for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:32:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26909 for ; Thu, 30 Oct 2003 10:32:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEn3-0004zY-00 for simple@ietf.org; Thu, 30 Oct 2003 10:32:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEn2-0004z2-00 for simple@ietf.org; Thu, 30 Oct 2003 10:32:48 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UFWHca008545 for ; Thu, 30 Oct 2003 10:32:17 -0500 (EST) Message-ID: <3FA12F00.2070201@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] update to xcap list spec Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:32:16 -0500 Content-Transfer-Encoding: 7bit Folks, As you may have noticed, I submitted a rev of the xcap list specification. There were some changes based on list discussion: * generalized it, so it talks about lists in general, not just presence lists, but defines a specific boolean flag called "subscribeable" which indicates that you can subscribe to the list. THe schema now explicitly allows other attributes from different namespaces that can specify different actions, for example, "messageable" * added the ability to include other lists by reference There are no open issues I am aware of. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 10:33:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27004 for ; Thu, 30 Oct 2003 10:33:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEnM-0001bw-V3 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:33:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFX8PD006186 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEnM-0001bh-PV for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 10:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26915; Thu, 30 Oct 2003 10:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEnJ-0004zp-00; Thu, 30 Oct 2003 10:33:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEnI-0004zm-00; Thu, 30 Oct 2003 10:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEnF-0001Wc-JN; Thu, 30 Oct 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEn9-0001Vr-B6 for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:32:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26909 for ; Thu, 30 Oct 2003 10:32:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEn3-0004zY-00 for simple@ietf.org; Thu, 30 Oct 2003 10:32:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEn2-0004z2-00 for simple@ietf.org; Thu, 30 Oct 2003 10:32:48 -0500 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UFWHca008545 for ; Thu, 30 Oct 2003 10:32:17 -0500 (EST) Message-ID: <3FA12F00.2070201@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] update to xcap list spec Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 10:32:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, As you may have noticed, I submitted a rev of the xcap list specification. There were some changes based on list discussion: * generalized it, so it talks about lists in general, not just presence lists, but defines a specific boolean flag called "subscribeable" which indicates that you can subscribe to the list. THe schema now explicitly allows other attributes from different namespaces that can specify different actions, for example, "messageable" * added the ability to include other lists by reference There are no open issues I am aware of. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 10:35:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27136; Thu, 30 Oct 2003 10:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEqD-00052t-00; Thu, 30 Oct 2003 10:36:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEqD-00052p-00; Thu, 30 Oct 2003 10:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEqA-0001qs-53; Thu, 30 Oct 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEq2-0001pr-8m for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:35:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27112 for ; Thu, 30 Oct 2003 10:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEpz-00052H-00 for simple@ietf.org; Thu, 30 Oct 2003 10:35:51 -0500 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEpz-00052E-00 for simple@ietf.org; Thu, 30 Oct 2003 10:35:51 -0500 Received: from nt-mail.tlv.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Thu, 30 Oct 2003 17:34:57 +0200 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id <4DPLY4G5>; Thu, 30 Oct 2003 17:34:57 +0200 Message-ID: <99FF181D4C99564F8D623069E1DDB25E3B8AE4@nt-mail.tlv.radvision.com> From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] Require header Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 17:34:54 +0200 Hi. Should a Notifier handling incoming Subscribe requests check the "Require" or the "Proxy-Require" header value? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 10:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27191 for ; Thu, 30 Oct 2003 10:36:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEqG-0001xG-WB for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:36:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFa8DI007508 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 10:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEqG-0001vj-KI for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 10:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27136; Thu, 30 Oct 2003 10:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEqD-00052t-00; Thu, 30 Oct 2003 10:36:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFEqD-00052p-00; Thu, 30 Oct 2003 10:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEqA-0001qs-53; Thu, 30 Oct 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEq2-0001pr-8m for simple@optimus.ietf.org; Thu, 30 Oct 2003 10:35:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27112 for ; Thu, 30 Oct 2003 10:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEpz-00052H-00 for simple@ietf.org; Thu, 30 Oct 2003 10:35:51 -0500 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1AFEpz-00052E-00 for simple@ietf.org; Thu, 30 Oct 2003 10:35:51 -0500 Received: from nt-mail.tlv.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Thu, 30 Oct 2003 17:34:57 +0200 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id <4DPLY4G5>; Thu, 30 Oct 2003 17:34:57 +0200 Message-ID: <99FF181D4C99564F8D623069E1DDB25E3B8AE4@nt-mail.tlv.radvision.com> From: Orly Rosenberg To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Simple] Require header Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 17:34:54 +0200 Hi. Should a Notifier handling incoming Subscribe requests check the "Require" or the "Proxy-Require" header value? Thanks, Orly Rosenberg. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 11:38:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29748; Thu, 30 Oct 2003 11:38:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFoI-00064Z-00; Thu, 30 Oct 2003 11:38:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFFoI-00064W-00; Thu, 30 Oct 2003 11:38:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFoB-0001Nm-Aw; Thu, 30 Oct 2003 11:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFo6-0001N7-4E for simple@optimus.ietf.org; Thu, 30 Oct 2003 11:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29744 for ; Thu, 30 Oct 2003 11:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFo4-00064L-00 for simple@ietf.org; Thu, 30 Oct 2003 11:37:57 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AFFo3-000648-00 for simple@ietf.org; Thu, 30 Oct 2003 11:37:56 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9UGbmLZ009969; Thu, 30 Oct 2003 11:37:48 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h9UGblg19968; Thu, 30 Oct 2003 11:37:48 -0500 Message-ID: <3FA13E5B.6020701@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031025 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Changes in xcap-auth References: <3FA12B97.5080408@dynamicsoft.com> In-Reply-To: <3FA12B97.5080408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 11:37:47 -0500 Content-Transfer-Encoding: 7bit > which I will post notes on. There is also a big question around how/if > the geopriv policy format aligns with this. The other main question is To provide some background to those not following the GEOPRIV discussions: For whatever reason, the I-D editor doesn't seem to have posted the document yet, even though it was submitted in time. In any event, it's at http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv-policy-00.html Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 11:38:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29790 for ; Thu, 30 Oct 2003 11:38:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFoK-0001Qq-J4 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 11:38:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UGcC7J005498 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 11:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFoK-0001QW-75 for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 11:38:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29748; Thu, 30 Oct 2003 11:38:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFoI-00064Z-00; Thu, 30 Oct 2003 11:38:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFFoI-00064W-00; Thu, 30 Oct 2003 11:38:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFoB-0001Nm-Aw; Thu, 30 Oct 2003 11:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFo6-0001N7-4E for simple@optimus.ietf.org; Thu, 30 Oct 2003 11:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29744 for ; Thu, 30 Oct 2003 11:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFo4-00064L-00 for simple@ietf.org; Thu, 30 Oct 2003 11:37:57 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AFFo3-000648-00 for simple@ietf.org; Thu, 30 Oct 2003 11:37:56 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9UGbmLZ009969; Thu, 30 Oct 2003 11:37:48 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h9UGblg19968; Thu, 30 Oct 2003 11:37:48 -0500 Message-ID: <3FA13E5B.6020701@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031025 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] Changes in xcap-auth References: <3FA12B97.5080408@dynamicsoft.com> In-Reply-To: <3FA12B97.5080408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 11:37:47 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > which I will post notes on. There is also a big question around how/if > the geopriv policy format aligns with this. The other main question is To provide some background to those not following the GEOPRIV discussions: For whatever reason, the I-D editor doesn't seem to have posted the document yet, even though it was submitted in time. In any event, it's at http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv-policy-00.html Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 12:01:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00658; Thu, 30 Oct 2003 12:01:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGAx-0006OY-00; Thu, 30 Oct 2003 12:01:35 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGAx-0006OV-00; Thu, 30 Oct 2003 12:01:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGAX-0003vE-T5; Thu, 30 Oct 2003 12:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFG9d-0003iJ-8m for simple@optimus.ietf.org; Thu, 30 Oct 2003 12:00:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00606 for ; Thu, 30 Oct 2003 12:00:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFG9b-0006Ne-00 for simple@ietf.org; Thu, 30 Oct 2003 12:00:11 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AFG9a-0006Lz-00 for simple@ietf.org; Thu, 30 Oct 2003 12:00:10 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16860; Thu, 30 Oct 2003 11:59:37 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04477; Thu, 30 Oct 2003 11:59:37 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Oct 2003 11:59:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B605F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Simple WG Subject: RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 11:59:36 -0500 Wellllllll You will note that: example.com is in direct opposition to what Geopriv does, which is the subject of a thread: https://www1.ietf.org/mail-archive/working-groups/geopriv/current/msg00080.h tml In short, geopriv-policy is specifically designed to have a single URI, so that you don't need to linear search and evaluate a set of rules to find out which one(s) apply to the request. , and would be precisely what geopriv-policy is trying to avoid. I'd prefer the xcap approach. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, October 30, 2003 11:38 AM > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] Changes in xcap-auth > > > > > which I will post notes on. There is also a big question > around how/if > > the geopriv policy format aligns with this. The other main > question is > > To provide some background to those not following the GEOPRIV > discussions: > > For whatever reason, the I-D editor doesn't seem to have posted the > document yet, even though it was submitted in time. In any > event, it's at > > http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv- > policy-00.html > > Henning > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 12:02:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00687 for ; Thu, 30 Oct 2003 12:02:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGAz-00045U-If for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 12:01:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UH1b42015712 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 12:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGAz-00045L-EQ for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 12:01:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00658; Thu, 30 Oct 2003 12:01:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGAx-0006OY-00; Thu, 30 Oct 2003 12:01:35 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGAx-0006OV-00; Thu, 30 Oct 2003 12:01:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGAX-0003vE-T5; Thu, 30 Oct 2003 12:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFG9d-0003iJ-8m for simple@optimus.ietf.org; Thu, 30 Oct 2003 12:00:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00606 for ; Thu, 30 Oct 2003 12:00:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFG9b-0006Ne-00 for simple@ietf.org; Thu, 30 Oct 2003 12:00:11 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AFG9a-0006Lz-00 for simple@ietf.org; Thu, 30 Oct 2003 12:00:10 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16860; Thu, 30 Oct 2003 11:59:37 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04477; Thu, 30 Oct 2003 11:59:37 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Oct 2003 11:59:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B605F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Simple WG Subject: RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 11:59:36 -0500 Wellllllll You will note that: example.com is in direct opposition to what Geopriv does, which is the subject of a thread: https://www1.ietf.org/mail-archive/working-groups/geopriv/current/msg00080.h tml In short, geopriv-policy is specifically designed to have a single URI, so that you don't need to linear search and evaluate a set of rules to find out which one(s) apply to the request. , and would be precisely what geopriv-policy is trying to avoid. I'd prefer the xcap approach. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, October 30, 2003 11:38 AM > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] Changes in xcap-auth > > > > > which I will post notes on. There is also a big question > around how/if > > the geopriv policy format aligns with this. The other main > question is > > To provide some background to those not following the GEOPRIV > discussions: > > For whatever reason, the I-D editor doesn't seem to have posted the > document yet, even though it was submitted in time. In any > event, it's at > > http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv- > policy-00.html > > Henning > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 12:39:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02263; Thu, 30 Oct 2003 12:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGlK-0006z1-00; Thu, 30 Oct 2003 12:39:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGlJ-0006yy-00; Thu, 30 Oct 2003 12:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGlB-00017G-6l; Thu, 30 Oct 2003 12:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGkX-000124-DI for simple@optimus.ietf.org; Thu, 30 Oct 2003 12:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02241 for ; Thu, 30 Oct 2003 12:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGkV-0006yN-00 for simple@ietf.org; Thu, 30 Oct 2003 12:38:19 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFGkU-0006xj-00 for simple@ietf.org; Thu, 30 Oct 2003 12:38:19 -0500 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UHbjca008653; Thu, 30 Oct 2003 12:37:46 -0500 (EST) Message-ID: <3FA14C62.9010404@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] Require header References: <99FF181D4C99564F8D623069E1DDB25E3B8AE4@nt-mail.tlv.radvision.com> In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E3B8AE4@nt-mail.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 12:37:38 -0500 Content-Transfer-Encoding: 7bit Require. A notifier is a UA. -Jonathan R. Orly Rosenberg wrote: > Hi. > > Should a Notifier handling incoming Subscribe requests check the "Require" > or the "Proxy-Require" header value? > > Thanks, > Orly Rosenberg. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 12:39:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02299 for ; Thu, 30 Oct 2003 12:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGlN-0001Ac-0Y for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 12:39:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UHdCDC004476 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 12:39:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGlM-0001A7-6C for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 12:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02263; Thu, 30 Oct 2003 12:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGlK-0006z1-00; Thu, 30 Oct 2003 12:39:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGlJ-0006yy-00; Thu, 30 Oct 2003 12:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGlB-00017G-6l; Thu, 30 Oct 2003 12:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGkX-000124-DI for simple@optimus.ietf.org; Thu, 30 Oct 2003 12:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02241 for ; Thu, 30 Oct 2003 12:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGkV-0006yN-00 for simple@ietf.org; Thu, 30 Oct 2003 12:38:19 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFGkU-0006xj-00 for simple@ietf.org; Thu, 30 Oct 2003 12:38:19 -0500 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9UHbjca008653; Thu, 30 Oct 2003 12:37:46 -0500 (EST) Message-ID: <3FA14C62.9010404@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orly Rosenberg CC: "'simple@ietf.org'" Subject: Re: [Simple] Require header References: <99FF181D4C99564F8D623069E1DDB25E3B8AE4@nt-mail.tlv.radvision.com> In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E3B8AE4@nt-mail.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 12:37:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Require. A notifier is a UA. -Jonathan R. Orly Rosenberg wrote: > Hi. > > Should a Notifier handling incoming Subscribe requests check the "Require" > or the "Proxy-Require" header value? > > Thanks, > Orly Rosenberg. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Oct 30 14:44:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06990; Thu, 30 Oct 2003 14:44:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIir-0000vO-00; Thu, 30 Oct 2003 14:44:45 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFIg0-0000qP-01; Thu, 30 Oct 2003 14:41:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFISh-0000wh-2x; Thu, 30 Oct 2003 14:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIOk-00083U-At for simple@optimus.ietf.org; Thu, 30 Oct 2003 14:23:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05567; Thu, 30 Oct 2003 14:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIOh-0000T2-00; Thu, 30 Oct 2003 14:23:55 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AFIOg-0000Si-00; Thu, 30 Oct 2003 14:23:54 -0500 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9UJNNw5022641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 30 Oct 2003 13:23:23 -0600 From: "Dean Willis" To: , , , , Message-ID: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Simple] Maintenance on softarmor web site Thursday 30Oct2003 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 13:23:04 -0600 Content-Transfer-Encoding: 7bit 1:30 PM USCST The main server (www.softarmor.com) will be down for the next few hours while I replace the OS. In the interim, if you need web content, it's available at http://kevlar.softarmor.com/ Anybody using the main box as a relay for email will also be affected. Cheers, -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Oct 30 14:45:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07097 for ; Thu, 30 Oct 2003 14:45:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIiv-00037l-GR for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 14:44:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UJinrD012005 for simple-archive@odin.ietf.org; Thu, 30 Oct 2003 14:44:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIiv-00037Y-CI for simple-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 14:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06990; Thu, 30 Oct 2003 14:44:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIir-0000vO-00; Thu, 30 Oct 2003 14:44:45 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFIg0-0000qP-01; Thu, 30 Oct 2003 14:41:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFISh-0000wh-2x; Thu, 30 Oct 2003 14:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIOk-00083U-At for simple@optimus.ietf.org; Thu, 30 Oct 2003 14:23:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05567; Thu, 30 Oct 2003 14:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIOh-0000T2-00; Thu, 30 Oct 2003 14:23:55 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AFIOg-0000Si-00; Thu, 30 Oct 2003 14:23:54 -0500 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9UJNNw5022641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 30 Oct 2003 13:23:23 -0600 From: "Dean Willis" To: , , , , Message-ID: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Simple] Maintenance on softarmor web site Thursday 30Oct2003 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 13:23:04 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 1:30 PM USCST The main server (www.softarmor.com) will be down for the next few hours while I replace the OS. In the interim, if you need web content, it's available at http://kevlar.softarmor.com/ Anybody using the main box as a relay for email will also be affected. Cheers, -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 01:00:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00405; Fri, 31 Oct 2003 01:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSKf-0001X6-00; Fri, 31 Oct 2003 01:00:25 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFSKe-0001X3-00; Fri, 31 Oct 2003 01:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSKK-0002ij-Ev; Fri, 31 Oct 2003 01:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSJS-0002cU-2I for simple@optimus.ietf.org; Fri, 31 Oct 2003 00:59:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00358; Fri, 31 Oct 2003 00:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSJO-0001Uo-00; Fri, 31 Oct 2003 00:59:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AFSJO-0001Ul-00; Fri, 31 Oct 2003 00:59:06 -0500 Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9V5x2v4007287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 23:59:03 -0600 Message-ID: <3FA1FA2A.6040003@softarmor.com> From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org, simple@ietf.org, xcon@ietf.org, iptel@ietf.org References: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> In-Reply-To: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] Maintenance on softarmor web site Thursday 30Oct2003 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 23:59:06 -0600 Content-Transfer-Encoding: 7bit Dean Willis wrote: > 1:30 PM USCST > > The main server (www.softarmor.com) will be down for the next few hours > while I replace the OS. > > In the interim, if you need web content, it's available at > http://kevlar.softarmor.com/ > > Anybody using the main box as a relay for email will also be affected. > > Cheers, > > -- > Dean Everything should be back in working order, I think. Maybe. Note that everything has been rekeyed. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 01:00:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00454 for ; Fri, 31 Oct 2003 01:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSKi-0002pg-K4 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 01:00:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V60Swl010882 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 01:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSKi-0002pR-EN for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 01:00:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00405; Fri, 31 Oct 2003 01:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSKf-0001X6-00; Fri, 31 Oct 2003 01:00:25 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFSKe-0001X3-00; Fri, 31 Oct 2003 01:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSKK-0002ij-Ev; Fri, 31 Oct 2003 01:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSJS-0002cU-2I for simple@optimus.ietf.org; Fri, 31 Oct 2003 00:59:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00358; Fri, 31 Oct 2003 00:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSJO-0001Uo-00; Fri, 31 Oct 2003 00:59:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AFSJO-0001Ul-00; Fri, 31 Oct 2003 00:59:06 -0500 Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9V5x2v4007287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 23:59:03 -0600 Message-ID: <3FA1FA2A.6040003@softarmor.com> From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org, simple@ietf.org, xcon@ietf.org, iptel@ietf.org References: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> In-Reply-To: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] Maintenance on softarmor web site Thursday 30Oct2003 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 23:59:06 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dean Willis wrote: > 1:30 PM USCST > > The main server (www.softarmor.com) will be down for the next few hours > while I replace the OS. > > In the interim, if you need web content, it's available at > http://kevlar.softarmor.com/ > > Anybody using the main box as a relay for email will also be affected. > > Cheers, > > -- > Dean Everything should be back in working order, I think. Maybe. Note that everything has been rekeyed. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 01:08:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00736; Fri, 31 Oct 2003 01:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSSA-0001d7-00; Fri, 31 Oct 2003 01:08:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFSS9-0001d3-00; Fri, 31 Oct 2003 01:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSS1-0004UG-6a; Fri, 31 Oct 2003 01:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSRV-0004Jv-B1 for simple@optimus.ietf.org; Fri, 31 Oct 2003 01:07:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00672 for ; Fri, 31 Oct 2003 01:07:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSRS-0001bZ-00 for simple@ietf.org; Fri, 31 Oct 2003 01:07:26 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1AFSRK-0001bC-00 for simple@ietf.org; Fri, 31 Oct 2003 01:07:22 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Fri, 31 Oct 2003 11:42:11 +0530 Delivered-To: ipgen-india.com-jijo@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 12207 invoked by uid 7010); Fri Oct 31 11:25:39 2003 Received: (sifymail 12203 invoked by uid 7010); 31 Oct 2003 11:25:39 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 31 Oct 2003 11:25:39 +0530 Received: (sifymail 32148 invoked by uid 7005); 31 Oct 2003 11:25:39 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 31 Oct 2003 11:25:39 +0530 Received: (sifymail 32108 invoked by uid 7005); 31 Oct 2003 11:25:37 +0530 Received: from 132.151.6.22 (HELO optimus.ietf.org) (132.151.6.22) by 202.144.76.19 with SMTP; 31 Oct 2003 11:25:37 +0530 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSKN-0002jf-5i; Fri, 31 Oct 2003 01:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSJS-0002cU-Bv for sip@optimus.ietf.org; Fri, 31 Oct 2003 00:59:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00358; Fri, 31 Oct 2003 00:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSJO-0001Uo-00; Fri, 31 Oct 2003 00:59:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AFSJO-0001Ul-00; Fri, 31 Oct 2003 00:59:06 -0500 Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9V5x2v4007287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 23:59:03 -0600 Message-ID: <3FA1FA2A.6040003@softarmor.com> From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org, simple@ietf.org, xcon@ietf.org, iptel@ietf.org References: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> In-Reply-To: <002201c39f1b$3dc54e20$e1036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] Maintenance on softarmor web site Thursday 30Oct2003 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Oct 2003 23:59:06 -0600 Content-Transfer-Encoding: 7bit Dean Willis wrote: > 1:30 PM USCST > > The main server (www.softarmor.com) will be down for the next few hours > while I replace the OS. > > In the interim, if you need web content, it's available at > http://kevlar.softarmor.com/ > > Anybody using the main box as a relay for email will also be affected. > > Cheers, > > -- > Dean Everything should be back in working order, I think. Maybe. Note that everything has been rekeyed. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 04:25:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18954; Fri, 31 Oct 2003 04:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVXk-0004Xo-00; Fri, 31 Oct 2003 04:26:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFVXk-0004Xk-00; Fri, 31 Oct 2003 04:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVXf-0002g8-1h; Fri, 31 Oct 2003 04:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVXX-0002f9-3K for simple@optimus.ietf.org; Fri, 31 Oct 2003 04:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18938; Fri, 31 Oct 2003 04:25:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVXU-0004XP-00; Fri, 31 Oct 2003 04:25:52 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AFVXT-0004XM-00; Fri, 31 Oct 2003 04:25:51 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9V9PoF06795; Fri, 31 Oct 2003 10:25:51 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h9V9Pns03598; Fri, 31 Oct 2003 10:25:49 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 10:25:37 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03B3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Rosen, Brian'" , "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Simple WG , "'geopriv@ietf.org'" Subject: RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 10:25:42 +0100 hi brian, you raised several issues here: to simplify conflict resolution and to prevent leaking of information we have tried to make the policies simpler. hence you only have permit-only. furthermore, due to the nature of geopriv we need to support additive permissions. policies which implement everything-except for xy or something similar make it very difficult to fulfil our requirements since you can easily create conflicts. with the policies defined today you have to search through all of them to determine the final permission. this is a result of the permit-only design criteria. with regard to the default rules we are still discussing how to support them without introducing too many problems. supporting groups is another issue. there are certainly ways to add more functionality here but a) is it really required and b) is it simple enough as an example: if you simply use the authenticated entity and you strip-off the user-name part to compare whether this user belongs to a certain group then you need to understand the structure of the identity. the identity depends on the authentication protocol and these identities might have a different structure (e.g. sip uri, nai, x.500, kerberos principal names,etc.). i can think of other approaches which are simpler but they might have other problems which we haven't thought of yet. in the past we have already considered some approaches which are much more powerful and flexible. our goal was to create something simple without fancy features (which prevents unintentional disclosure of privacy related information). ciao hannes > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, October 30, 2003 6:00 PM > To: 'Henning Schulzrinne'; Jonathan Rosenberg > Cc: Simple WG > Subject: RE: [Simple] Changes in xcap-auth > > > Wellllllll > > You will note that: > > > > example.com > > > > is in direct opposition to what Geopriv does, which is the > subject of a thread: > https://www1.ietf.org/mail-archive/working-groups/geopriv/curr ent/msg00080.h tml In short, geopriv-policy is specifically designed to have a single URI, so that you don't need to linear search and evaluate a set of rules to find out which one(s) apply to the request. , and would be precisely what geopriv-policy is trying to avoid. I'd prefer the xcap approach. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, October 30, 2003 11:38 AM > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] Changes in xcap-auth > > > > > which I will post notes on. There is also a big question > around how/if > > the geopriv policy format aligns with this. The other main > question is > > To provide some background to those not following the GEOPRIV > discussions: > > For whatever reason, the I-D editor doesn't seem to have posted the > document yet, even though it was submitted in time. In any > event, it's at > > http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv- > policy-00.html > > Henning > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 04:26:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19009 for ; Fri, 31 Oct 2003 04:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVXo-0002if-Gx for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 04:26:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V9QCJX010447 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 04:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVXn-0002iQ-VI for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 04:26:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18954; Fri, 31 Oct 2003 04:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVXk-0004Xo-00; Fri, 31 Oct 2003 04:26:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFVXk-0004Xk-00; Fri, 31 Oct 2003 04:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVXf-0002g8-1h; Fri, 31 Oct 2003 04:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVXX-0002f9-3K for simple@optimus.ietf.org; Fri, 31 Oct 2003 04:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18938; Fri, 31 Oct 2003 04:25:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVXU-0004XP-00; Fri, 31 Oct 2003 04:25:52 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AFVXT-0004XM-00; Fri, 31 Oct 2003 04:25:51 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9V9PoF06795; Fri, 31 Oct 2003 10:25:51 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h9V9Pns03598; Fri, 31 Oct 2003 10:25:49 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 10:25:37 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03B3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Rosen, Brian'" , "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Simple WG , "'geopriv@ietf.org'" Subject: RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 10:25:42 +0100 hi brian, you raised several issues here: to simplify conflict resolution and to prevent leaking of information we have tried to make the policies simpler. hence you only have permit-only. furthermore, due to the nature of geopriv we need to support additive permissions. policies which implement everything-except for xy or something similar make it very difficult to fulfil our requirements since you can easily create conflicts. with the policies defined today you have to search through all of them to determine the final permission. this is a result of the permit-only design criteria. with regard to the default rules we are still discussing how to support them without introducing too many problems. supporting groups is another issue. there are certainly ways to add more functionality here but a) is it really required and b) is it simple enough as an example: if you simply use the authenticated entity and you strip-off the user-name part to compare whether this user belongs to a certain group then you need to understand the structure of the identity. the identity depends on the authentication protocol and these identities might have a different structure (e.g. sip uri, nai, x.500, kerberos principal names,etc.). i can think of other approaches which are simpler but they might have other problems which we haven't thought of yet. in the past we have already considered some approaches which are much more powerful and flexible. our goal was to create something simple without fancy features (which prevents unintentional disclosure of privacy related information). ciao hannes > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, October 30, 2003 6:00 PM > To: 'Henning Schulzrinne'; Jonathan Rosenberg > Cc: Simple WG > Subject: RE: [Simple] Changes in xcap-auth > > > Wellllllll > > You will note that: > > > > example.com > > > > is in direct opposition to what Geopriv does, which is the > subject of a thread: > https://www1.ietf.org/mail-archive/working-groups/geopriv/curr ent/msg00080.h tml In short, geopriv-policy is specifically designed to have a single URI, so that you don't need to linear search and evaluate a set of rules to find out which one(s) apply to the request. , and would be precisely what geopriv-policy is trying to avoid. I'd prefer the xcap approach. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, October 30, 2003 11:38 AM > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] Changes in xcap-auth > > > > > which I will post notes on. There is also a big question > around how/if > > the geopriv policy format aligns with this. The other main > question is > > To provide some background to those not following the GEOPRIV > discussions: > > For whatever reason, the I-D editor doesn't seem to have posted the > document yet, even though it was submitted in time. In any > event, it's at > > http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv- > policy-00.html > > Henning > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 07:46:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25586; Fri, 31 Oct 2003 07:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFYfv-0007Ed-00; Fri, 31 Oct 2003 07:46:47 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFYfv-0007Ea-00; Fri, 31 Oct 2003 07:46:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYfB-0007jF-S9; Fri, 31 Oct 2003 07:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYf6-0007it-5v for simple@optimus.ietf.org; Fri, 31 Oct 2003 07:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25464 for ; Fri, 31 Oct 2003 07:45:44 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFYf5-0007Ch-00 for simple@ietf.org; Fri, 31 Oct 2003 07:45:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AFYf4-0007Ce-00 for simple@ietf.org; Fri, 31 Oct 2003 07:45:54 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9VCjrF21059 for ; Fri, 31 Oct 2003 14:45:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Oct 2003 14:45:52 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Oct 2003 14:45:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBCE@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Thread-Index: AcOdabzzOYK6oU/rSdSfRiZ02wbPcACImEBg To: , X-OriginalArrivalTime: 31 Oct 2003 12:45:52.0841 (UTC) FILETIME=[EB5C9390:01C39FAC] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 14:45:52 +0200 Content-Transfer-Encoding: quoted-printable Hi Paul, Inline: >=20 > I see that this revision has tried to align the format of the new > elements with the other elements in PIDF and RPIDS.=20 > Stylistically that=20 > is good. >=20 > But, in the process, something important has been lost. In > draft-ietf-sip-callee-caps-01 there is the possibility of using both=20 > base-tags defined explicitly in that document, and other-tags. But=20 > prescaps only represents the base-tags. I think it is important to=20 > provide a representation for those as well. Yes, I also think that support for other-tags would be good. During update I wasn't able to come up with any good solution so I just dropped it. =20 > Additionally, the xml representations of the values for > base-tags does=20 > not cover the range of possibilities defined in callee-caps. Could you be bit more specific. Do you meant that for example for element XML schema should define the exact structure how method names should be presented? > In spite of this (or perhaps because of it) there is a nice=20 > simplicity=20 > to the elements now defined in the document. >=20 > To fix the limitations, I suggest that one other element be defined:=20 > . Unlike the base tags where we can bake in the particular=20 > value representation that is permitted, for we can't know=20 > which specific value representation is appropriate, and so=20 > must support=20 > all the possibilities. I can see a few ways to do this: >=20 > 1) use what was proposed in draft-lonnfors-simple-prescaps-ext-01. >=20 > pros: we already have a proposal for it > cons: it has a bug - can't distinguish between token > and string values; its kind of wordy >=20 > 2) use the literal string representation used in contact headers > in draft-ietf-sip-callee-caps-01. >=20 > pros: the mapping is straightforward; it covers all cases; > easy to use the same matching algorithm with both > presence data and registration data >=20 > cons: it isn't very user friendly if ever presented directly > to a user; it isn't a very convenient representation > for code that doesn't need to implement the matching alg. I am not sure if this is that big problem. I would think that if client does not know how what particular attribute means it probably won't display it to the user. At least you probably cannot expect client to take any actions based on attributes which it doesn't understand.=20 > 3) convert the value to rfc 2533 format, and embed that in=20 > the element. >=20 > pros: the mapping is well defined and covers all the cases; > convenient for someone implementing the matching alg > by literally using 2533. > cons: truly an arcane representation; very inconvenient for > anyone not implementing 2533 literally; doesn't lend > itself to representing each "other-tag" and value > separately. >=20 > I conclude that (2) is probably the best overall. (Other=20 > opinions welcome.) For me option 2 sounds ok. I will modify draft accordingly if nobody objects. There are also some other open issues with existing draft and I will try to compose a separate mail about those before the next meeting. - Mikko > The following is the example from prescaps, extended in this way: >=20 > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:pidf" > xmlns:ext=3D"urn:ietf:params:xml:ns:simple-prescaps-ext" > entity=3D"pres:someone@example.com"> >=20 > > > open > > true > true > true > INVITE,MESSAGE, > ACK,BYE,CANCEL > > #=3D5,!#<=3D10 > > !en > > !red,blue > > TRUE > > > sip:someone@examaple.com > > >=20 > This is equivalent to the following contact: >=20 > Contact: sip:someone@examaple.com; > video;audio;mobile; > methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > +sip.priority=3D"#=3D5,!#<=3D10" > +language=3D"!en"; > +g.sip!foo@tags.example.com=3D"!red,blue"; > +g.sip!bar@tags.example.com; >=20 > or equivalently: >=20 > Contact: sip:someone@examaple.com; > video;audio;mobile; > methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > priority=3D"#=3D5,!#<=3D10"; > language=3D"!en" > +g.sip!foo@tags.example.com=3D"!red,blue"; > +g.sip!bar@tags.example.com >=20 > Note that not only does this address other tags, it also addresses=20 > values for base-tags that are more complex than the simple=20 > representation can handle. >=20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 07:47:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25678 for ; Fri, 31 Oct 2003 07:47:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYfx-0007na-2c for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 07:46:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VCknd5029974 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 07:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYfw-0007nN-Ue for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 07:46:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25586; Fri, 31 Oct 2003 07:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFYfv-0007Ed-00; Fri, 31 Oct 2003 07:46:47 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFYfv-0007Ea-00; Fri, 31 Oct 2003 07:46:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYfB-0007jF-S9; Fri, 31 Oct 2003 07:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYf6-0007it-5v for simple@optimus.ietf.org; Fri, 31 Oct 2003 07:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25464 for ; Fri, 31 Oct 2003 07:45:44 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFYf5-0007Ch-00 for simple@ietf.org; Fri, 31 Oct 2003 07:45:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AFYf4-0007Ce-00 for simple@ietf.org; Fri, 31 Oct 2003 07:45:54 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9VCjrF21059 for ; Fri, 31 Oct 2003 14:45:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Oct 2003 14:45:52 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Oct 2003 14:45:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBCE@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Thread-Index: AcOdabzzOYK6oU/rSdSfRiZ02wbPcACImEBg To: , X-OriginalArrivalTime: 31 Oct 2003 12:45:52.0841 (UTC) FILETIME=[EB5C9390:01C39FAC] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 14:45:52 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Paul, Inline: >=20 > I see that this revision has tried to align the format of the new > elements with the other elements in PIDF and RPIDS.=20 > Stylistically that=20 > is good. >=20 > But, in the process, something important has been lost. In > draft-ietf-sip-callee-caps-01 there is the possibility of using both=20 > base-tags defined explicitly in that document, and other-tags. But=20 > prescaps only represents the base-tags. I think it is important to=20 > provide a representation for those as well. Yes, I also think that support for other-tags would be good. During update I wasn't able to come up with any good solution so I just dropped it. =20 > Additionally, the xml representations of the values for > base-tags does=20 > not cover the range of possibilities defined in callee-caps. Could you be bit more specific. Do you meant that for example for element XML schema should define the exact structure how method names should be presented? > In spite of this (or perhaps because of it) there is a nice=20 > simplicity=20 > to the elements now defined in the document. >=20 > To fix the limitations, I suggest that one other element be defined:=20 > . Unlike the base tags where we can bake in the particular=20 > value representation that is permitted, for we can't know=20 > which specific value representation is appropriate, and so=20 > must support=20 > all the possibilities. I can see a few ways to do this: >=20 > 1) use what was proposed in draft-lonnfors-simple-prescaps-ext-01. >=20 > pros: we already have a proposal for it > cons: it has a bug - can't distinguish between token > and string values; its kind of wordy >=20 > 2) use the literal string representation used in contact headers > in draft-ietf-sip-callee-caps-01. >=20 > pros: the mapping is straightforward; it covers all cases; > easy to use the same matching algorithm with both > presence data and registration data >=20 > cons: it isn't very user friendly if ever presented directly > to a user; it isn't a very convenient representation > for code that doesn't need to implement the matching alg. I am not sure if this is that big problem. I would think that if client does not know how what particular attribute means it probably won't display it to the user. At least you probably cannot expect client to take any actions based on attributes which it doesn't understand.=20 > 3) convert the value to rfc 2533 format, and embed that in=20 > the element. >=20 > pros: the mapping is well defined and covers all the cases; > convenient for someone implementing the matching alg > by literally using 2533. > cons: truly an arcane representation; very inconvenient for > anyone not implementing 2533 literally; doesn't lend > itself to representing each "other-tag" and value > separately. >=20 > I conclude that (2) is probably the best overall. (Other=20 > opinions welcome.) For me option 2 sounds ok. I will modify draft accordingly if nobody objects. There are also some other open issues with existing draft and I will try to compose a separate mail about those before the next meeting. - Mikko > The following is the example from prescaps, extended in this way: >=20 > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:pidf" > xmlns:ext=3D"urn:ietf:params:xml:ns:simple-prescaps-ext" > entity=3D"pres:someone@example.com"> >=20 > > > open > > true > true > true > INVITE,MESSAGE, > ACK,BYE,CANCEL > > #=3D5,!#<=3D10 > > !en > > !red,blue > > TRUE > > > sip:someone@examaple.com > > >=20 > This is equivalent to the following contact: >=20 > Contact: sip:someone@examaple.com; > video;audio;mobile; > methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > +sip.priority=3D"#=3D5,!#<=3D10" > +language=3D"!en"; > +g.sip!foo@tags.example.com=3D"!red,blue"; > +g.sip!bar@tags.example.com; >=20 > or equivalently: >=20 > Contact: sip:someone@examaple.com; > video;audio;mobile; > methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > priority=3D"#=3D5,!#<=3D10"; > language=3D"!en" > +g.sip!foo@tags.example.com=3D"!red,blue"; > +g.sip!bar@tags.example.com >=20 > Note that not only does this address other tags, it also addresses=20 > values for base-tags that are more complex than the simple=20 > representation can handle. >=20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 09:41:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29924; Fri, 31 Oct 2003 09:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaTO-0000sn-00; Fri, 31 Oct 2003 09:41:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFaTN-0000sk-00; Fri, 31 Oct 2003 09:41:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaST-0005z4-C5; Fri, 31 Oct 2003 09:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaRk-0005rY-Pi for simple@optimus.ietf.org; Fri, 31 Oct 2003 09:40:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29759 for ; Fri, 31 Oct 2003 09:40:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaRi-0000rI-00 for simple@ietf.org; Fri, 31 Oct 2003 09:40:14 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 1AFaRi-0000qu-00 for simple@ietf.org; Fri, 31 Oct 2003 09:40:14 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VEdduT020819; Fri, 31 Oct 2003 09:39:41 -0500 (EST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP74654; Fri, 31 Oct 2003 09:39:38 -0500 (EST) Message-ID: <3FA2742A.2020209@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBCE@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 09:39:38 -0500 Content-Transfer-Encoding: 7bit Mikko - response inline. Paul mikko.lonnfors@nokia.com wrote: > Hi Paul, > > Inline: > >>I see that this revision has tried to align the format of the new >>elements with the other elements in PIDF and RPIDS. >>Stylistically that >>is good. >> >>But, in the process, something important has been lost. In >>draft-ietf-sip-callee-caps-01 there is the possibility of using both >>base-tags defined explicitly in that document, and other-tags. But >>prescaps only represents the base-tags. I think it is important to >>provide a representation for those as well. > > > Yes, I also think that support for other-tags would be good. During > update I wasn't able to come up with any good solution so I just dropped > it. > > >>Additionally, the xml representations of the values for >>base-tags does >>not cover the range of possibilities defined in callee-caps. > > > Could you be bit more specific. Do you meant that for example for > element XML schema should define the exact structure how > method names should be presented? No. I mean your xml format doesn't cover: - negation - number ranges - distinction between tokens and strings (tokens use case-insensitive compare, strings use case-sensitive compare) >>2) use the literal string representation used in contact headers >> in draft-ietf-sip-callee-caps-01. >> >> pros: the mapping is straightforward; it covers all cases; >> easy to use the same matching algorithm with both >> presence data and registration data >> >> cons: it isn't very user friendly if ever presented directly >> to a user; it isn't a very convenient representation >> for code that doesn't need to implement the matching alg. > > > I am not sure if this is that big problem. I would think that if client > does not know how what particular attribute means it probably won't > display it to the user. At least you probably cannot expect client to > take any actions based on attributes which it doesn't understand. You will note that I concluded this was the best alternative in spite of the limitations. I mentioned them in the interest of trying to do an honest evaluation of the alternatives. > For me option 2 sounds ok. I will modify draft accordingly if nobody > objects. Sounds good to me, but it would be nice to get input from others. If you look closely at the examples I provided, I sidestepped one issue: I didn't show how to represent the distinction between strings and tokens. In callee-caps it is done as "token" vs "". My xml skills aren't very good, and so I don't have a clear idea what would be the best way to render this difference in xml. But I do know that rendering: description="" as: is *not* the answer! So I need a suggestion from somebody on how best to do this. > There are also some other open issues with existing draft and I will try > to compose a separate mail about those before the next meeting. > > - Mikko > > >>The following is the example from prescaps, extended in this way: >> >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:ietf:params:xml:ns:pidf" >> xmlns:ext="urn:ietf:params:xml:ns:simple-prescaps-ext" >> entity="pres:someone@example.com"> >> >> >> >> open >> >> true >> true >> true >> INVITE,MESSAGE, >> ACK,BYE,CANCEL >> >> #=5,!#<=10 >> >> !en >> >> !red,blue >> >> TRUE >> >> >> sip:someone@examaple.com >> >> >> >>This is equivalent to the following contact: >> >> Contact: sip:someone@examaple.com; >> video;audio;mobile; >> methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; >> +sip.priority="#=5,!#<=10" >> +language="!en"; >> +g.sip!foo@tags.example.com="!red,blue"; >> +g.sip!bar@tags.example.com; >> >>or equivalently: >> >> Contact: sip:someone@examaple.com; >> video;audio;mobile; >> methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; >> priority="#=5,!#<=10"; >> language="!en" >> +g.sip!foo@tags.example.com="!red,blue"; >> +g.sip!bar@tags.example.com >> >>Note that not only does this address other tags, it also addresses >>values for base-tags that are more complex than the simple >>representation can handle. >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 09:42:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29952 for ; Fri, 31 Oct 2003 09:42:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaTQ-00068R-Qv for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 09:42:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VEg0FJ023577 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 09:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaTQ-00068C-Ng for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 09:42:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29924; Fri, 31 Oct 2003 09:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaTO-0000sn-00; Fri, 31 Oct 2003 09:41:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFaTN-0000sk-00; Fri, 31 Oct 2003 09:41:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaST-0005z4-C5; Fri, 31 Oct 2003 09:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaRk-0005rY-Pi for simple@optimus.ietf.org; Fri, 31 Oct 2003 09:40:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29759 for ; Fri, 31 Oct 2003 09:40:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaRi-0000rI-00 for simple@ietf.org; Fri, 31 Oct 2003 09:40:14 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 1AFaRi-0000qu-00 for simple@ietf.org; Fri, 31 Oct 2003 09:40:14 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VEdduT020819; Fri, 31 Oct 2003 09:39:41 -0500 (EST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP74654; Fri, 31 Oct 2003 09:39:38 -0500 (EST) Message-ID: <3FA2742A.2020209@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBCE@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 09:39:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mikko - response inline. Paul mikko.lonnfors@nokia.com wrote: > Hi Paul, > > Inline: > >>I see that this revision has tried to align the format of the new >>elements with the other elements in PIDF and RPIDS. >>Stylistically that >>is good. >> >>But, in the process, something important has been lost. In >>draft-ietf-sip-callee-caps-01 there is the possibility of using both >>base-tags defined explicitly in that document, and other-tags. But >>prescaps only represents the base-tags. I think it is important to >>provide a representation for those as well. > > > Yes, I also think that support for other-tags would be good. During > update I wasn't able to come up with any good solution so I just dropped > it. > > >>Additionally, the xml representations of the values for >>base-tags does >>not cover the range of possibilities defined in callee-caps. > > > Could you be bit more specific. Do you meant that for example for > element XML schema should define the exact structure how > method names should be presented? No. I mean your xml format doesn't cover: - negation - number ranges - distinction between tokens and strings (tokens use case-insensitive compare, strings use case-sensitive compare) >>2) use the literal string representation used in contact headers >> in draft-ietf-sip-callee-caps-01. >> >> pros: the mapping is straightforward; it covers all cases; >> easy to use the same matching algorithm with both >> presence data and registration data >> >> cons: it isn't very user friendly if ever presented directly >> to a user; it isn't a very convenient representation >> for code that doesn't need to implement the matching alg. > > > I am not sure if this is that big problem. I would think that if client > does not know how what particular attribute means it probably won't > display it to the user. At least you probably cannot expect client to > take any actions based on attributes which it doesn't understand. You will note that I concluded this was the best alternative in spite of the limitations. I mentioned them in the interest of trying to do an honest evaluation of the alternatives. > For me option 2 sounds ok. I will modify draft accordingly if nobody > objects. Sounds good to me, but it would be nice to get input from others. If you look closely at the examples I provided, I sidestepped one issue: I didn't show how to represent the distinction between strings and tokens. In callee-caps it is done as "token" vs "". My xml skills aren't very good, and so I don't have a clear idea what would be the best way to render this difference in xml. But I do know that rendering: description="" as: is *not* the answer! So I need a suggestion from somebody on how best to do this. > There are also some other open issues with existing draft and I will try > to compose a separate mail about those before the next meeting. > > - Mikko > > >>The following is the example from prescaps, extended in this way: >> >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:ietf:params:xml:ns:pidf" >> xmlns:ext="urn:ietf:params:xml:ns:simple-prescaps-ext" >> entity="pres:someone@example.com"> >> >> >> >> open >> >> true >> true >> true >> INVITE,MESSAGE, >> ACK,BYE,CANCEL >> >> #=5,!#<=10 >> >> !en >> >> !red,blue >> >> TRUE >> >> >> sip:someone@examaple.com >> >> >> >>This is equivalent to the following contact: >> >> Contact: sip:someone@examaple.com; >> video;audio;mobile; >> methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; >> +sip.priority="#=5,!#<=10" >> +language="!en"; >> +g.sip!foo@tags.example.com="!red,blue"; >> +g.sip!bar@tags.example.com; >> >>or equivalently: >> >> Contact: sip:someone@examaple.com; >> video;audio;mobile; >> methods="INVITE,MESSAGE,ACK,BYE,CANCEL"; >> priority="#=5,!#<=10"; >> language="!en" >> +g.sip!foo@tags.example.com="!red,blue"; >> +g.sip!bar@tags.example.com >> >>Note that not only does this address other tags, it also addresses >>values for base-tags that are more complex than the simple >>representation can handle. >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 10:05:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01312; Fri, 31 Oct 2003 10:05:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaqN-0001K1-00; Fri, 31 Oct 2003 10:05:43 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFaqN-0001Jy-00; Fri, 31 Oct 2003 10:05:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFapj-0000Y2-1k; Fri, 31 Oct 2003 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFapN-0000WZ-Ef for simple@optimus.ietf.org; Fri, 31 Oct 2003 10:04:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01148; Fri, 31 Oct 2003 10:04:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFapK-0001Is-00; Fri, 31 Oct 2003 10:04:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFapK-0001I1-00; Fri, 31 Oct 2003 10:04:38 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9VF3tca009286; Fri, 31 Oct 2003 10:03:55 -0500 (EST) Message-ID: <3FA279D9.7020305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: "'Rosen, Brian'" , "'Henning Schulzrinne'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03B3@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC03B3@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 10:03:53 -0500 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi brian, > > you raised several issues here: > > to simplify conflict resolution and to prevent leaking of information we > have tried to make the policies simpler. hence you only have permit-only. > furthermore, due to the nature of geopriv we need to support additive > permissions. policies which implement everything-except for xy or something > similar make it very difficult to fulfil our requirements since you can > easily create conflicts. xcap-auth also only uses additive permissions. The applies-to section is the ONLY place which specifies exceptions. These exceptions only specify to whom a particular permission applies. Thus, there are no conflicts. From the introduction: > granted to those watchers. The concept of a permission is central to > this specification. A permission is an atomic statement of consent. A > permission can indicate a condition under which a subscription is > accepted or rejected, a condition under which a notification is or is > not sent, or a piece of information which is revealed in a presence > document. The overall authorization for a watcher is represented by > the union of the permissions granted to that watcher. > > with the policies defined today you have to search through all of them to > determine the final permission. this is a result of the permit-only design > criteria. I do not think an xcap implementation would need to search through all statements to determine which ones apply. We are *not* supporting general regular expressions. Statements apply to domain, URI (either listed explicitly or reference from another list), or anyone - thats it. There are no other granularity of permissions. THe implication is that an implementation can easily compute two tables, one indexed by URI, and one by domain, which point to the relevant permissions for that uri or domain. > > with regard to the default rules we are still discussing how to support them > without introducing too many problems. > > supporting groups is another issue. there are certainly ways to add more > functionality here but > a) is it really required and > b) is it simple enough I'm not sure what you mean by groups? > > as an example: if you simply use the authenticated entity and you strip-off > the user-name part to compare whether this user belongs to a certain group > then you need to understand the structure of the identity. the identity > depends on the authentication protocol and these identities might have a > different structure (e.g. sip uri, nai, x.500, kerberos principal > names,etc.). i can think of other approaches which are simpler but they > might have other problems which we haven't thought of yet. > > in the past we have already considered some approaches which are much more > powerful and flexible. our goal was to create something simple without fancy > features (which prevents unintentional disclosure of privacy related > information). It seems simple and geopriv are aligned on these goals. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 10:06:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01417 for ; Fri, 31 Oct 2003 10:06:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaqR-0000fX-2r for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 10:05:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VF5lqs002563 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 10:05:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaqQ-0000fG-V5 for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 10:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01312; Fri, 31 Oct 2003 10:05:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaqN-0001K1-00; Fri, 31 Oct 2003 10:05:43 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFaqN-0001Jy-00; Fri, 31 Oct 2003 10:05:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFapj-0000Y2-1k; Fri, 31 Oct 2003 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFapN-0000WZ-Ef for simple@optimus.ietf.org; Fri, 31 Oct 2003 10:04:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01148; Fri, 31 Oct 2003 10:04:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFapK-0001Is-00; Fri, 31 Oct 2003 10:04:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFapK-0001I1-00; Fri, 31 Oct 2003 10:04:38 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9VF3tca009286; Fri, 31 Oct 2003 10:03:55 -0500 (EST) Message-ID: <3FA279D9.7020305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: "'Rosen, Brian'" , "'Henning Schulzrinne'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03B3@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC03B3@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 10:03:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi brian, > > you raised several issues here: > > to simplify conflict resolution and to prevent leaking of information we > have tried to make the policies simpler. hence you only have permit-only. > furthermore, due to the nature of geopriv we need to support additive > permissions. policies which implement everything-except for xy or something > similar make it very difficult to fulfil our requirements since you can > easily create conflicts. xcap-auth also only uses additive permissions. The applies-to section is the ONLY place which specifies exceptions. These exceptions only specify to whom a particular permission applies. Thus, there are no conflicts. From the introduction: > granted to those watchers. The concept of a permission is central to > this specification. A permission is an atomic statement of consent. A > permission can indicate a condition under which a subscription is > accepted or rejected, a condition under which a notification is or is > not sent, or a piece of information which is revealed in a presence > document. The overall authorization for a watcher is represented by > the union of the permissions granted to that watcher. > > with the policies defined today you have to search through all of them to > determine the final permission. this is a result of the permit-only design > criteria. I do not think an xcap implementation would need to search through all statements to determine which ones apply. We are *not* supporting general regular expressions. Statements apply to domain, URI (either listed explicitly or reference from another list), or anyone - thats it. There are no other granularity of permissions. THe implication is that an implementation can easily compute two tables, one indexed by URI, and one by domain, which point to the relevant permissions for that uri or domain. > > with regard to the default rules we are still discussing how to support them > without introducing too many problems. > > supporting groups is another issue. there are certainly ways to add more > functionality here but > a) is it really required and > b) is it simple enough I'm not sure what you mean by groups? > > as an example: if you simply use the authenticated entity and you strip-off > the user-name part to compare whether this user belongs to a certain group > then you need to understand the structure of the identity. the identity > depends on the authentication protocol and these identities might have a > different structure (e.g. sip uri, nai, x.500, kerberos principal > names,etc.). i can think of other approaches which are simpler but they > might have other problems which we haven't thought of yet. > > in the past we have already considered some approaches which are much more > powerful and flexible. our goal was to create something simple without fancy > features (which prevents unintentional disclosure of privacy related > information). It seems simple and geopriv are aligned on these goals. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 10:30:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03576; Fri, 31 Oct 2003 10:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbEy-0001nF-00; Fri, 31 Oct 2003 10:31:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFbEx-0001mv-00; Fri, 31 Oct 2003 10:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbEs-0003rO-33; Fri, 31 Oct 2003 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbEP-0003oA-Su for simple@optimus.ietf.org; Fri, 31 Oct 2003 10:30:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03495; Fri, 31 Oct 2003 10:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbEN-0001li-00; Fri, 31 Oct 2003 10:30:31 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AFbEM-0001lf-00; Fri, 31 Oct 2003 10:30:30 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9VFUSF07934; Fri, 31 Oct 2003 16:30:28 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h9VFUQs10721; Fri, 31 Oct 2003 16:30:27 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 16:30:13 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" Cc: "'Rosen, Brian'" , "'Henning Schulzrinne'" , Simple WG , "'geopriv@ietf.org'" Subject: RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 16:30:18 +0100 hi jonathan, thanks for your comments. > > > Tschofenig Hannes wrote: > > > hi brian, > > > > you raised several issues here: > > > > to simplify conflict resolution and to prevent leaking of > information we > > have tried to make the policies simpler. hence you only > have permit-only. > > furthermore, due to the nature of geopriv we need to > support additive > > permissions. policies which implement everything-except for > xy or something > > similar make it very difficult to fulfil our requirements > since you can > > easily create conflicts. > > xcap-auth also only uses additive permissions. The applies-to section > is the ONLY place which specifies exceptions. These exceptions only > specify to whom a particular permission applies. Thus, there are no > conflicts. From the introduction: > > > granted to those watchers. The concept of a permission is > central to > > this specification. A permission is an atomic statement > of consent. A > > permission can indicate a condition under which a subscription is > > accepted or rejected, a condition under which a > notification is or is > > not sent, or a piece of information which is revealed in > a presence > > document. The overall authorization for a watcher is > represented by > > the union of the permissions granted to that watcher. > i guess we should have used a different term here in our draft. it might create confusions. immagine the following case: you have two rule sets (A and B). rule set A specifies: everyone from dynamicsoft.com is allowed to access location information of henning with granularity X and is allowed to distribute it further to other people. rule set B specifies: access to location info for henning is allowed with ... except for jdrosen@dynamicsoft.com. the problem here: policies are allowed to be distributed in geopriv and can always have the case where you cannot access rule set B (e.g., external reference does not work). hence the additional rule set (B in this case) should only add permissions and should revoke some of them. > > > > > > > with the policies defined today you have to search through > all of them to > > determine the final permission. this is a result of the > permit-only design > > criteria. > > I do not think an xcap implementation would need to search > through all > statements to determine which ones apply. We are *not* supporting > general regular expressions. Statements apply to domain, URI (either > listed explicitly or reference from another list), or anyone - thats > it. There are no other granularity of permissions. THe implication is > that an implementation can easily compute two tables, one indexed by > URI, and one by domain, which point to the relevant permissions for > that uri or domain. as described in our document you have to search through the entire table (conceptually) since you might have several matches and the final permission is computed based on the set of firing rules. however, i agree with you that an actual implementation might have several choices to use internal data structures. by leaning on a relational database model you could certainly benefit from optimization techniques known there to make the access more efficient. if you look at regular packet filtering mechanisms then you do not compute the permissions of the entire rule set. instead you often terminate once you have the first match (i.e., rules are typically ordered). we do not want such an ordering. > > > > > with regard to the default rules we are still discussing > how to support them > > without introducing too many problems. > > > > supporting groups is another issue. there are certainly > ways to add more > > functionality here but > > a) is it really required and > > b) is it simple enough > > I'm not sure what you mean by groups? group: an identifier which refers to a group of people instead of only an individual. > > > > > as an example: if you simply use the authenticated entity > and you strip-off > > the user-name part to compare whether this user belongs to > a certain group > > then you need to understand the structure of the identity. > the identity > > depends on the authentication protocol and these identities > might have a > > different structure (e.g. sip uri, nai, x.500, kerberos principal > > names,etc.). i can think of other approaches which are > simpler but they > > might have other problems which we haven't thought of yet. > > > > in the past we have already considered some approaches > which are much more > > powerful and flexible. our goal was to create something > simple without fancy > > features (which prevents unintentional disclosure of privacy related > > information). > > It seems simple and geopriv are aligned on these goals. that's great. over the past few months we tried to align the two authorization policies. ciao hannes > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 10:31:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03676 for ; Fri, 31 Oct 2003 10:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbF3-0003u7-EB for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 10:31:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VFVDBG015000 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 10:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbF2-0003tq-GZ for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 10:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03576; Fri, 31 Oct 2003 10:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbEy-0001nF-00; Fri, 31 Oct 2003 10:31:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFbEx-0001mv-00; Fri, 31 Oct 2003 10:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbEs-0003rO-33; Fri, 31 Oct 2003 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbEP-0003oA-Su for simple@optimus.ietf.org; Fri, 31 Oct 2003 10:30:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03495; Fri, 31 Oct 2003 10:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbEN-0001li-00; Fri, 31 Oct 2003 10:30:31 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AFbEM-0001lf-00; Fri, 31 Oct 2003 10:30:30 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9VFUSF07934; Fri, 31 Oct 2003 16:30:28 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h9VFUQs10721; Fri, 31 Oct 2003 16:30:27 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 16:30:13 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" Cc: "'Rosen, Brian'" , "'Henning Schulzrinne'" , Simple WG , "'geopriv@ietf.org'" Subject: RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 16:30:18 +0100 hi jonathan, thanks for your comments. > > > Tschofenig Hannes wrote: > > > hi brian, > > > > you raised several issues here: > > > > to simplify conflict resolution and to prevent leaking of > information we > > have tried to make the policies simpler. hence you only > have permit-only. > > furthermore, due to the nature of geopriv we need to > support additive > > permissions. policies which implement everything-except for > xy or something > > similar make it very difficult to fulfil our requirements > since you can > > easily create conflicts. > > xcap-auth also only uses additive permissions. The applies-to section > is the ONLY place which specifies exceptions. These exceptions only > specify to whom a particular permission applies. Thus, there are no > conflicts. From the introduction: > > > granted to those watchers. The concept of a permission is > central to > > this specification. A permission is an atomic statement > of consent. A > > permission can indicate a condition under which a subscription is > > accepted or rejected, a condition under which a > notification is or is > > not sent, or a piece of information which is revealed in > a presence > > document. The overall authorization for a watcher is > represented by > > the union of the permissions granted to that watcher. > i guess we should have used a different term here in our draft. it might create confusions. immagine the following case: you have two rule sets (A and B). rule set A specifies: everyone from dynamicsoft.com is allowed to access location information of henning with granularity X and is allowed to distribute it further to other people. rule set B specifies: access to location info for henning is allowed with ... except for jdrosen@dynamicsoft.com. the problem here: policies are allowed to be distributed in geopriv and can always have the case where you cannot access rule set B (e.g., external reference does not work). hence the additional rule set (B in this case) should only add permissions and should revoke some of them. > > > > > > > with the policies defined today you have to search through > all of them to > > determine the final permission. this is a result of the > permit-only design > > criteria. > > I do not think an xcap implementation would need to search > through all > statements to determine which ones apply. We are *not* supporting > general regular expressions. Statements apply to domain, URI (either > listed explicitly or reference from another list), or anyone - thats > it. There are no other granularity of permissions. THe implication is > that an implementation can easily compute two tables, one indexed by > URI, and one by domain, which point to the relevant permissions for > that uri or domain. as described in our document you have to search through the entire table (conceptually) since you might have several matches and the final permission is computed based on the set of firing rules. however, i agree with you that an actual implementation might have several choices to use internal data structures. by leaning on a relational database model you could certainly benefit from optimization techniques known there to make the access more efficient. if you look at regular packet filtering mechanisms then you do not compute the permissions of the entire rule set. instead you often terminate once you have the first match (i.e., rules are typically ordered). we do not want such an ordering. > > > > > with regard to the default rules we are still discussing > how to support them > > without introducing too many problems. > > > > supporting groups is another issue. there are certainly > ways to add more > > functionality here but > > a) is it really required and > > b) is it simple enough > > I'm not sure what you mean by groups? group: an identifier which refers to a group of people instead of only an individual. > > > > > as an example: if you simply use the authenticated entity > and you strip-off > > the user-name part to compare whether this user belongs to > a certain group > > then you need to understand the structure of the identity. > the identity > > depends on the authentication protocol and these identities > might have a > > different structure (e.g. sip uri, nai, x.500, kerberos principal > > names,etc.). i can think of other approaches which are > simpler but they > > might have other problems which we haven't thought of yet. > > > > in the past we have already considered some approaches > which are much more > > powerful and flexible. our goal was to create something > simple without fancy > > features (which prevents unintentional disclosure of privacy related > > information). > > It seems simple and geopriv are aligned on these goals. that's great. over the past few months we tried to align the two authorization policies. ciao hannes > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 10:39:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04127; Fri, 31 Oct 2003 10:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbNG-0001wA-00; Fri, 31 Oct 2003 10:39:42 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFbNG-0001w7-00; Fri, 31 Oct 2003 10:39:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbMa-0004wf-W4; Fri, 31 Oct 2003 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbMJ-0004u6-Iw for simple@optimus.ietf.org; Fri, 31 Oct 2003 10:38:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04046 for ; Fri, 31 Oct 2003 10:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbMH-0001v0-00 for simple@ietf.org; Fri, 31 Oct 2003 10:38:41 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFbMG-0001uC-00 for simple@ietf.org; Fri, 31 Oct 2003 10:38:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9VFc7d02874 for ; Fri, 31 Oct 2003 09:38:07 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1067614685.945.13.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE meeting in Minneapolis Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 09:38:06 -0600 Content-Transfer-Encoding: 7bit This is a proposed agenda for the Minneapolis SIMPLE meeting. Please comment on missing topics and topic durations. Do not spend time commenting on which session a topic is in or relative ordering of topics. That is likely to change between now and when we submit this to the IETF agenda next week. 2.5 hour slot: (currently scheduled Thu 0900-1130) 0h 10m : Agenda bashing, status 1h 00m : msrp (Ben) 0h 35m : pdoc-usage (Robert) 0h 45m : xcap (Jonathan) 2 hour slot (currently scheduled Thu 1300-1500) 0h 15m : filtering (Hisham) 0h 15m : xcap-publish-usage (Markus) 0h 15m : partial-notification (Mikko) 0h 15m : presence/im-wireless-reqs (Aki/Krisztian) 0h 15m : timed-presence (Henning) 0h 15m : winfo-history (Aki) 0h 15m : adhoc-event-list (Orit) 0h 15m : summary, review of assigned actions Henning does not believe we need to schedule dedicated time for RPID.is needed at this meeting _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 10:40:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04177 for ; Fri, 31 Oct 2003 10:40:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbNJ-00053O-Th for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 10:39:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VFdjUc019420 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 10:39:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbNJ-000539-Ne for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 10:39:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04127; Fri, 31 Oct 2003 10:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbNG-0001wA-00; Fri, 31 Oct 2003 10:39:42 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFbNG-0001w7-00; Fri, 31 Oct 2003 10:39:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbMa-0004wf-W4; Fri, 31 Oct 2003 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbMJ-0004u6-Iw for simple@optimus.ietf.org; Fri, 31 Oct 2003 10:38:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04046 for ; Fri, 31 Oct 2003 10:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbMH-0001v0-00 for simple@ietf.org; Fri, 31 Oct 2003 10:38:41 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFbMG-0001uC-00 for simple@ietf.org; Fri, 31 Oct 2003 10:38:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h9VFc7d02874 for ; Fri, 31 Oct 2003 09:38:07 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1067614685.945.13.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE meeting in Minneapolis Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 09:38:06 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a proposed agenda for the Minneapolis SIMPLE meeting. Please comment on missing topics and topic durations. Do not spend time commenting on which session a topic is in or relative ordering of topics. That is likely to change between now and when we submit this to the IETF agenda next week. 2.5 hour slot: (currently scheduled Thu 0900-1130) 0h 10m : Agenda bashing, status 1h 00m : msrp (Ben) 0h 35m : pdoc-usage (Robert) 0h 45m : xcap (Jonathan) 2 hour slot (currently scheduled Thu 1300-1500) 0h 15m : filtering (Hisham) 0h 15m : xcap-publish-usage (Markus) 0h 15m : partial-notification (Mikko) 0h 15m : presence/im-wireless-reqs (Aki/Krisztian) 0h 15m : timed-presence (Henning) 0h 15m : winfo-history (Aki) 0h 15m : adhoc-event-list (Orit) 0h 15m : summary, review of assigned actions Henning does not believe we need to schedule dedicated time for RPID.is needed at this meeting _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 14:01:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13469; Fri, 31 Oct 2003 14:01:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeWJ-0005J8-00; Fri, 31 Oct 2003 14:01:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFeWI-0005J5-00; Fri, 31 Oct 2003 14:01:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeW6-0003py-MM; Fri, 31 Oct 2003 14:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeVw-0003fm-L2 for simple@optimus.ietf.org; Fri, 31 Oct 2003 14:00:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13408 for ; Fri, 31 Oct 2003 14:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeVu-0005IO-00 for simple@ietf.org; Fri, 31 Oct 2003 14:00:50 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFeVt-0005Hg-00 for simple@ietf.org; Fri, 31 Oct 2003 14:00:49 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9VJ0Cca009421; Fri, 31 Oct 2003 14:00:13 -0500 (EST) Message-ID: <3FA2B13B.6010401@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 14:00:11 -0500 Content-Transfer-Encoding: 7bit Sorry for the late response. I thank you very much for your comments on this document; its great to have a real HTTP expert take a look at it. responses inline. Scott Lawrence wrote: > I've started studying the XCAP proposals, and have a first couple of > suggestions for the framwork draft: > > ==== > > In section 4, the Application Usage ID id defined using one of two > namespaces, an implicit IETF namespace that controls all names not > prefixed by 'vnd.' and the vendor namespace for all names that do have > that prefix. I would suggest a single uniform naming convention, > already familiar to any Java programmer: invert the order in a DNS > domain name controlled by the entity defining the usage. All > IETF-defined names would be prefixed by 'org.ietf' (and registered > with IANA); any Pingtel-defined name would be prefixed 'com.pingtel'. This is an area were there are many different approaches across IETF protocols. The proposal in the xcap draft mirrored the rfc2506 media feature tag registration procedures. Anyway, I do think it makes sense to use the java naming convention for vendor tags. I would prefer to have a separate ietf namespace, and so I kept that. > > I think that the intent in section 5 is that the Node-Selector be > passed in the HTTP query string component of the URI (though it is not > phrased that way). If so, the syntax from the draft: > > XCAP-URI = Document-URI ["?" Node-Selector] > > is redundant, since a URI may include a query string (incidentally, > there is a bug in RFC 2616 with respect to this, which may be where > this came from - see the errata list [1]). This syntax actually > allows http://example.com/foo?query?node-selector, which I'm sure was > not your intent. No. Actually, in the -01 version, I dropped the grammar completely. An xcap URI *is* an HTTP URI, so I didnt want to specify a separate grammar for it. I merely gave names to the two pieces (the document URI and node selector), and said that the node selector is the HTTP query string, and the document URI is the rest of the URI. I think that a more appropriate mechanism for > specifying a component would be to pass it as a fragment identifier > (defined in RFC 2396 [URI Generic Syntax], section 4.1), which is > appended to (but not a part of) the URI separated by the '#' > character. This construction is a URI reference, so the suggested > syntax would be: > > XCAP-URI-reference = Document-URI ["#" Node-Selector] > > this is exactly what fragment identifiers are for. We discussed this at the interim meeting. The problem is that the fragment identifiers are not passed on the wire to the server. They are evaluated locally. Here, we want the server to evaluate the fragment identifier, and just return that portion of the document. So, we kept the query string approach. It had also been proposed to simply continue to use the "/" hierarchy all the way down into the XML document, i.e.: http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/ resource-list[@id="assd99"] where the last two components of the path identify XML elements. I didnt like this, since practically speaking, implementations are likely going to want to use the filesystem or DB to retrieve a specific document, and then use some XML processing to retrieve an element or attribute. So, knowing where the breakpoint is in the URI is helpful, I think. > In addition to the > syntactic problem above, using a query string may interact poorly in > some HTTP server implementations when the method is not GET. Really? This is worth testing, I think. We need it with PUT and DELETE. Any volunteers to run a few tests on few servers? Should be an easy one. > > On the node-selector itself, did you consider using XPointer [2] rather > than XPath? I'm still studying these myself, but on first look, > XPointer (whose purpose is to provide an xml fragment identifier > syntax) looks sufficient for XCAP and much simpler. I spent some time looking at xpointer. Here is what I learned. Xpointer provides a generic framework (http://www.w3.org/TR/xptr-framework/) this framework doesnt do more than allow different schemes for identifying XML components. Then, it defines a few specific schemes. http://www.w3.org/TR/xptr-element/ allows for addressing of elements by position. However, it *only* allows for order-based addressing, i.e.: /root-element/2/3/4/3/2 after the element name at the top, each fragment of the path after that is an integer that identifies a position in the document. Thats not sufficient for us, I dont think. It makes the adressing brittle. There is no way to have a way to identify a specific buddy, for example, where the reference would remain valid after changes and additions have been made to the document. In the xcap usages I have designed so far, I have been adding id elements to the schema to faciliate very targeted addressing using the element[@att="val"] Xpath approach. Using the xptr-element approach means that, for all intents and purposes, a client will need to pull the whole doc in order to be sure its pointing to the right element for addressing a DELETE or PUT to modify it. Given that wireless is our #1 customer for this, I am concerned about that. There is another Xpointer scheme for some kind of namespace mapping (http://www.w3.org/TR/xptr-xmlns/). The other xpointer spec, yet unfinished, uses xpath and allows for identification of elements (http://www.w3.org/TR/xptr-xpointer/). Whats interesting about it, is that it is a SUPERSET of Xpath. That is, in addition to all the capabilities in Xpath, it adds a few more functions, including some range functions that allow for document selection by character position. So, given that our aim is to use less of Xpath rather than more, and given that Xpointer usin Xpath is as yet unfinished, I didnt think it was a good match for us. Instead, in the -01 version I submitted, I defined our own mini-xpath that provides just a few ways of addressing elements. > > ==== > > The draft suggests using the HTTP conditional request mechanisms based > on date-time stamps, which were inherited from HTTP/1.0 by HTTP/1.1. > I would suggest that using the HTTP/1.1 Etag mechanism would be a > better choice. A conditional fetch uses an If-None-Match header, > holding the Etag value returned with the cached version of the > resource; a conditional PUT, POST, or DELETE uses a If-Match header > holding the Etag value. There is some text in 2616 on the use of > 'weak' etag values - in effect, this can be safely ignored (just don't > use the explicit weak etag syntax and it all becomes a no-op). From > the client side, Etags are used in the same way date-times _should_ be > used - as opaque strings, but because the server is free to construct > Etag values in any way that preserves the match/no-match semantics, > rather than being limited to a particular time-value syntax, Etags > allow the server freedom to do smarter things internally (the etag > value could be a unique database key, or a document hash, for > example). I'm sold. The -01 version now makes use of Etags per your suggestion. Thanks for your comments. I welcome any other thoughts you might have on xcap. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 14:01:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13518 for ; Fri, 31 Oct 2003 14:01:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeWM-0003t6-4s for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 14:01:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VJ1I58014940 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 14:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeWM-0003st-0b for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 14:01:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13469; Fri, 31 Oct 2003 14:01:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeWJ-0005J8-00; Fri, 31 Oct 2003 14:01:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFeWI-0005J5-00; Fri, 31 Oct 2003 14:01:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeW6-0003py-MM; Fri, 31 Oct 2003 14:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeVw-0003fm-L2 for simple@optimus.ietf.org; Fri, 31 Oct 2003 14:00:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13408 for ; Fri, 31 Oct 2003 14:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeVu-0005IO-00 for simple@ietf.org; Fri, 31 Oct 2003 14:00:50 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFeVt-0005Hg-00 for simple@ietf.org; Fri, 31 Oct 2003 14:00:49 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9VJ0Cca009421; Fri, 31 Oct 2003 14:00:13 -0500 (EST) Message-ID: <3FA2B13B.6010401@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 14:00:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the late response. I thank you very much for your comments on this document; its great to have a real HTTP expert take a look at it. responses inline. Scott Lawrence wrote: > I've started studying the XCAP proposals, and have a first couple of > suggestions for the framwork draft: > > ==== > > In section 4, the Application Usage ID id defined using one of two > namespaces, an implicit IETF namespace that controls all names not > prefixed by 'vnd.' and the vendor namespace for all names that do have > that prefix. I would suggest a single uniform naming convention, > already familiar to any Java programmer: invert the order in a DNS > domain name controlled by the entity defining the usage. All > IETF-defined names would be prefixed by 'org.ietf' (and registered > with IANA); any Pingtel-defined name would be prefixed 'com.pingtel'. This is an area were there are many different approaches across IETF protocols. The proposal in the xcap draft mirrored the rfc2506 media feature tag registration procedures. Anyway, I do think it makes sense to use the java naming convention for vendor tags. I would prefer to have a separate ietf namespace, and so I kept that. > > I think that the intent in section 5 is that the Node-Selector be > passed in the HTTP query string component of the URI (though it is not > phrased that way). If so, the syntax from the draft: > > XCAP-URI = Document-URI ["?" Node-Selector] > > is redundant, since a URI may include a query string (incidentally, > there is a bug in RFC 2616 with respect to this, which may be where > this came from - see the errata list [1]). This syntax actually > allows http://example.com/foo?query?node-selector, which I'm sure was > not your intent. No. Actually, in the -01 version, I dropped the grammar completely. An xcap URI *is* an HTTP URI, so I didnt want to specify a separate grammar for it. I merely gave names to the two pieces (the document URI and node selector), and said that the node selector is the HTTP query string, and the document URI is the rest of the URI. I think that a more appropriate mechanism for > specifying a component would be to pass it as a fragment identifier > (defined in RFC 2396 [URI Generic Syntax], section 4.1), which is > appended to (but not a part of) the URI separated by the '#' > character. This construction is a URI reference, so the suggested > syntax would be: > > XCAP-URI-reference = Document-URI ["#" Node-Selector] > > this is exactly what fragment identifiers are for. We discussed this at the interim meeting. The problem is that the fragment identifiers are not passed on the wire to the server. They are evaluated locally. Here, we want the server to evaluate the fragment identifier, and just return that portion of the document. So, we kept the query string approach. It had also been proposed to simply continue to use the "/" hierarchy all the way down into the XML document, i.e.: http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/ resource-list[@id="assd99"] where the last two components of the path identify XML elements. I didnt like this, since practically speaking, implementations are likely going to want to use the filesystem or DB to retrieve a specific document, and then use some XML processing to retrieve an element or attribute. So, knowing where the breakpoint is in the URI is helpful, I think. > In addition to the > syntactic problem above, using a query string may interact poorly in > some HTTP server implementations when the method is not GET. Really? This is worth testing, I think. We need it with PUT and DELETE. Any volunteers to run a few tests on few servers? Should be an easy one. > > On the node-selector itself, did you consider using XPointer [2] rather > than XPath? I'm still studying these myself, but on first look, > XPointer (whose purpose is to provide an xml fragment identifier > syntax) looks sufficient for XCAP and much simpler. I spent some time looking at xpointer. Here is what I learned. Xpointer provides a generic framework (http://www.w3.org/TR/xptr-framework/) this framework doesnt do more than allow different schemes for identifying XML components. Then, it defines a few specific schemes. http://www.w3.org/TR/xptr-element/ allows for addressing of elements by position. However, it *only* allows for order-based addressing, i.e.: /root-element/2/3/4/3/2 after the element name at the top, each fragment of the path after that is an integer that identifies a position in the document. Thats not sufficient for us, I dont think. It makes the adressing brittle. There is no way to have a way to identify a specific buddy, for example, where the reference would remain valid after changes and additions have been made to the document. In the xcap usages I have designed so far, I have been adding id elements to the schema to faciliate very targeted addressing using the element[@att="val"] Xpath approach. Using the xptr-element approach means that, for all intents and purposes, a client will need to pull the whole doc in order to be sure its pointing to the right element for addressing a DELETE or PUT to modify it. Given that wireless is our #1 customer for this, I am concerned about that. There is another Xpointer scheme for some kind of namespace mapping (http://www.w3.org/TR/xptr-xmlns/). The other xpointer spec, yet unfinished, uses xpath and allows for identification of elements (http://www.w3.org/TR/xptr-xpointer/). Whats interesting about it, is that it is a SUPERSET of Xpath. That is, in addition to all the capabilities in Xpath, it adds a few more functions, including some range functions that allow for document selection by character position. So, given that our aim is to use less of Xpath rather than more, and given that Xpointer usin Xpath is as yet unfinished, I didnt think it was a good match for us. Instead, in the -01 version I submitted, I defined our own mini-xpath that provides just a few ways of addressing elements. > > ==== > > The draft suggests using the HTTP conditional request mechanisms based > on date-time stamps, which were inherited from HTTP/1.0 by HTTP/1.1. > I would suggest that using the HTTP/1.1 Etag mechanism would be a > better choice. A conditional fetch uses an If-None-Match header, > holding the Etag value returned with the cached version of the > resource; a conditional PUT, POST, or DELETE uses a If-Match header > holding the Etag value. There is some text in 2616 on the use of > 'weak' etag values - in effect, this can be safely ignored (just don't > use the explicit weak etag syntax and it all becomes a no-op). From > the client side, Etags are used in the same way date-times _should_ be > used - as opaque strings, but because the server is free to construct > Etag values in any way that preserves the match/no-match semantics, > rather than being limited to a particular time-value syntax, Etags > allow the server freedom to do smarter things internally (the etag > value could be a unique database key, or a document hash, for > example). I'm sold. The -01 version now makes use of Etags per your suggestion. Thanks for your comments. I welcome any other thoughts you might have on xcap. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Oct 31 15:00:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16479; Fri, 31 Oct 2003 15:00:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfSD-0006L4-00; Fri, 31 Oct 2003 15:01:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFfSC-0006Kz-00; Fri, 31 Oct 2003 15:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfSA-0001t2-GR; Fri, 31 Oct 2003 15:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfRS-0001pG-18 for simple@optimus.ietf.org; Fri, 31 Oct 2003 15:00:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16428 for ; Fri, 31 Oct 2003 15:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfRO-0006Ju-00 for simple@ietf.org; Fri, 31 Oct 2003 15:00:14 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFfRO-0006HK-00 for simple@ietf.org; Fri, 31 Oct 2003 15:00:14 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9VJxgca009446; Fri, 31 Oct 2003 14:59:44 -0500 (EST) Message-ID: <3FA2BF2C.7030202@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naoko ITO CC: simple@ietf.org Subject: Re: [Simple] Questions on XCAP Usage for Authorization References: <007501c389b2$7c4470f0$33e2110a@lab5.netlab.nec.co.jp> In-Reply-To: <007501c389b2$7c4470f0$33e2110a@lab5.netlab.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 14:59:40 -0500 Content-Transfer-Encoding: 7bit Sorry for the delay in responding. Answers inline. Naoko ITO wrote: > Hello, > > I have some questions on XCAP Usage for Authorization. > > The draft says, > The overall authorization for a watcher is represented by the union > of the permissions granted to that watcher. > and > In that case, the union of the permissions across those statements > is applied to the subscription. > > Am I correctly understanding that the overall authorization is > determined by simply putting together every permission related to a > specific watcher? Yes. > > Then, some questions occur to me. > > - Is there any way to reject a watcher who is given permissions by > other statements? > ex) Give a permission to any user whose domain is "example.com" but > Joe. Yes, now that is possible in -01. You would define a statement that allows anyone but Joe: example.com sip:joe@example.com and to reject Joe, there would be this statement: sip:joe@example.com Note how, in the second statement, there is an applies-to, but *no* permissions. I.e., the way to reject someone is that they are granted no permissions. > - Is there a way to have a default policy which can be overridden by > other statements? It seems possible to reject, or not to give a > permission to all the watchers by default and add permisions to > specific users only. But it does not seem possible to accept every > user by default unless listed on a black list. Sure, you can do that. You would have two-statements: http://xcap.example.com/resource-lists/users/joe/ black-list http://xcap.example.com/resource-lists/users/joe/ black-list This is now possible because of the except clause which I added in -01. > - How to solve the conflicts between two or more permissions related to > one watcher? Ahh, thats the whole idea. There *can't* be conflicts. By defining the permissions as additive always, you never have conflicts. Geopriv has taken the exact same approach. > > I understand this is still under discussion, as it says, > > OPEN ISSUE: Another model is that you take permissions for the > most specific match. I think union makes more sense in the model > where the entries in the statement are permissions. > > but it'd be greatful if I can be provided any idea on this. I think we've concluded here. I believe that the appropriate model is as specified. With the addition of the except clause, I am confident that we can easily specify a wide range of things, and furthermore, have a model which always maximizes privacy. You never have to worry about information being given out by accident because some blocking rule was overriden with a permission rule. People only get information when they are granted an explicit permission. Given that geopriv has also chosen this model, its clear to me that its the right way to go. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Oct 31 15:01:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16515 for ; Fri, 31 Oct 2003 15:01:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfSG-0001x3-Ob for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 15:01:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VK18wO007487 for simple-archive@odin.ietf.org; Fri, 31 Oct 2003 15:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfSG-0001wg-KX for simple-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 15:01:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16479; Fri, 31 Oct 2003 15:00:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfSD-0006L4-00; Fri, 31 Oct 2003 15:01:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFfSC-0006Kz-00; Fri, 31 Oct 2003 15:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfSA-0001t2-GR; Fri, 31 Oct 2003 15:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfRS-0001pG-18 for simple@optimus.ietf.org; Fri, 31 Oct 2003 15:00:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16428 for ; Fri, 31 Oct 2003 15:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfRO-0006Ju-00 for simple@ietf.org; Fri, 31 Oct 2003 15:00:14 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFfRO-0006HK-00 for simple@ietf.org; Fri, 31 Oct 2003 15:00:14 -0500 Received: from dynamicsoft.com ([63.113.46.6]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9VJxgca009446; Fri, 31 Oct 2003 14:59:44 -0500 (EST) Message-ID: <3FA2BF2C.7030202@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naoko ITO CC: simple@ietf.org Subject: Re: [Simple] Questions on XCAP Usage for Authorization References: <007501c389b2$7c4470f0$33e2110a@lab5.netlab.nec.co.jp> In-Reply-To: <007501c389b2$7c4470f0$33e2110a@lab5.netlab.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Oct 2003 14:59:40 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the delay in responding. Answers inline. Naoko ITO wrote: > Hello, > > I have some questions on XCAP Usage for Authorization. > > The draft says, > The overall authorization for a watcher is represented by the union > of the permissions granted to that watcher. > and > In that case, the union of the permissions across those statements > is applied to the subscription. > > Am I correctly understanding that the overall authorization is > determined by simply putting together every permission related to a > specific watcher? Yes. > > Then, some questions occur to me. > > - Is there any way to reject a watcher who is given permissions by > other statements? > ex) Give a permission to any user whose domain is "example.com" but > Joe. Yes, now that is possible in -01. You would define a statement that allows anyone but Joe: example.com sip:joe@example.com and to reject Joe, there would be this statement: sip:joe@example.com Note how, in the second statement, there is an applies-to, but *no* permissions. I.e., the way to reject someone is that they are granted no permissions. > - Is there a way to have a default policy which can be overridden by > other statements? It seems possible to reject, or not to give a > permission to all the watchers by default and add permisions to > specific users only. But it does not seem possible to accept every > user by default unless listed on a black list. Sure, you can do that. You would have two-statements: http://xcap.example.com/resource-lists/users/joe/ black-list http://xcap.example.com/resource-lists/users/joe/ black-list This is now possible because of the except clause which I added in -01. > - How to solve the conflicts between two or more permissions related to > one watcher? Ahh, thats the whole idea. There *can't* be conflicts. By defining the permissions as additive always, you never have conflicts. Geopriv has taken the exact same approach. > > I understand this is still under discussion, as it says, > > OPEN ISSUE: Another model is that you take permissions for the > most specific match. I think union makes more sense in the model > where the entries in the statement are permissions. > > but it'd be greatful if I can be provided any idea on this. I think we've concluded here. I believe that the appropriate model is as specified. With the addition of the except clause, I am confident that we can easily specify a wide range of things, and furthermore, have a model which always maximizes privacy. You never have to worry about information being given out by accident because some blocking rule was overriden with a permission rule. People only get information when they are granted an explicit permission. Given that geopriv has also chosen this model, its clear to me that its the right way to go. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple