From simple-bounces@ietf.org Tue Jun 1 01:39:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08837 for ; Tue, 1 Jun 2004 01:39:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV1zH-0003gK-6v for simple-archive@ietf.org; Tue, 01 Jun 2004 01:38:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV1yK-0003Ec-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 01:38:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV1xN-0002kF-00; Tue, 01 Jun 2004 01:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV1qe-0004RR-TH; Tue, 01 Jun 2004 01:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV1pE-0004HH-Ny for simple@megatron.ietf.org; Tue, 01 Jun 2004 01:28: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 BAA08505 for ; Tue, 1 Jun 2004 01:28:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV1pC-0007AN-NV for simple@ietf.org; Tue, 01 Jun 2004 01:28:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV1oD-0006k4-00 for simple@ietf.org; Tue, 01 Jun 2004 01:27:33 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BV1nE-0006KH-00 for simple@ietf.org; Tue, 01 Jun 2004 01:26:33 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i515MYo16339; Tue, 1 Jun 2004 08:22:35 +0300 (EET DST) X-Scanned: Tue, 1 Jun 2004 08:22:29 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i515MTq6027756; Tue, 1 Jun 2004 08:22:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00LdfDX0; Tue, 01 Jun 2004 08:22:28 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i515MSH24665; Tue, 1 Jun 2004 08:22:28 +0300 (EET DST) Received: from nokia.com ([172.21.40.141]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Jun 2004 08:22:27 +0300 Message-ID: <40BC1292.2070403@nokia.com> Date: Tue, 01 Jun 2004 08:22:26 +0300 From: Miguel 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-es MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-iscomposing-01.txt References: <200405171947.PAA19409@ietf.org> <40A9A52B.7040408@nokia.com> <40BB9BD9.7000104@cs.columbia.edu> In-Reply-To: <40BB9BD9.7000104@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2004 05:22:27.0543 (UTC) FILETIME=[6DC4C670:01C44798] Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi: I checked the schema with XMLSpy and it validates correctly. BR, Miguel Henning Schulzrinne wrote: > Thanks for checking. I think I finally got them all: > > http://www.cs.columbia.edu/sip/draft/iscomposing/draft-ietf-simple-iscomposing-02.html > > http://www.cs.columbia.edu/sip/draft/iscomposing/draft-ietf-simple-iscomposing-02.txt > > > I will submit the new drafts tomorrow. > > (Unfortunately, XMLSpy doesn't seem to catch out-of-order elements, even > with processContents="strict".) > > Miguel Garcia wrote: > >> I'm sorry to be picky on this, but XMLSpy gives an error when I try to >> validate the schema. >> >> Apparently XMLSpy does not like an followed by a : >> >> >> >> >> >> But inserting a in between seems solve the problem: >> >> >> >> >> >> This one seems to be OK to me, but folks please check if this is correct. >> >> Another comment: the example in section 5 provides a >> element. It should be . Additionally, the example does not >> follow the same order of elements declared in the schema. The order >> should be: >> >> >> >> >> >> >> Regards, >> >> Miguel >> >> >> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 1 01:40:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08885 for ; Tue, 1 Jun 2004 01:40:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV20J-000493-2b for simple-archive@ietf.org; Tue, 01 Jun 2004 01:40:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV1zH-0003gV-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 01:39:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV1yN-0003Br-00; Tue, 01 Jun 2004 01:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV1qf-0004RW-93; Tue, 01 Jun 2004 01:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV1pG-0004HL-9y for simple@megatron.ietf.org; Tue, 01 Jun 2004 01:28: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 BAA08513 for ; Tue, 1 Jun 2004 01:28:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV1pE-0007AX-6j for simple@ietf.org; Tue, 01 Jun 2004 01:28:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV1oG-0006kR-00 for simple@ietf.org; Tue, 01 Jun 2004 01:27:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BV1na-00069m-00 for simple@ietf.org; Tue, 01 Jun 2004 01:26:54 -0400 Received: from dynamicsoft.com ([63.113.46.57]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i515NDbo014204; Tue, 1 Jun 2004 01:23:14 -0400 (EDT) Message-ID: <40BC12AF.8090608@dynamicsoft.com> Date: Tue, 01 Jun 2004 01:22:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> In-Reply-To: <40B6A050.9040304@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > We had a related debate in other contexts before (rules?), about > referencing XML entities from elsewhere. Generally, this seems to get > messy quickly. I don't see what's wrong with the simple model: > > (1) contact-less tuple represents the presentity (my best guess what the > presentity as a person is doing) > (2) contact-equipped tuples can be either devices (which also is an > instance of a service) or services (hiding several similar devices > behind one URI), with a label if that is helpful The problem here is that a device can host a multiplicity of services (my cell phone), each of which may have radically different URI, and that a device itself is not well described by a single contact address. However, you say something important in your suggestion, which is "contact-equipped tuples can be either devices (which also is an instance of a service)". My proposal for what "device view" means was that you have a tuple that represents all of the services available on a particular device, by doing a pivot operation on that device. In that way, the service tuple "represents" a device, in that I'm trying to have a single tuple for each device. However, the tuple is still fundamentally describing a service, NOT a device. > > Both (1) and (2) can contain RPID and CIPID information (the latter > probably only for tuples). If (2) contains RPID > information, it means that it refers to the device or service. Which? What would it mean when I have devices that support multiple services, and a multiplicity of services that can run on a single device? -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-bounces@ietf.org Tue Jun 1 01:44:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09129 for ; Tue, 1 Jun 2004 01:44:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV24m-0006Jw-Mg for simple-archive@ietf.org; Tue, 01 Jun 2004 01:44:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV23q-0005sU-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 01:43:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV22v-00051m-00; Tue, 01 Jun 2004 01:42:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV1yz-0005Vk-8Q; Tue, 01 Jun 2004 01:38:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV1v3-0004rJ-Nh for simple@megatron.ietf.org; Tue, 01 Jun 2004 01:34: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 BAA08659 for ; Tue, 1 Jun 2004 01:34:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV1v1-0001tw-NZ for simple@ietf.org; Tue, 01 Jun 2004 01:34:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV1u4-0001UY-00 for simple@ietf.org; Tue, 01 Jun 2004 01:33:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BV1td-00014n-00 for simple@ietf.org; Tue, 01 Jun 2004 01:33:10 -0400 Received: from dynamicsoft.com ([63.113.46.57]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i515U7bo014214; Tue, 1 Jun 2004 01:30:07 -0400 (EDT) Message-ID: <40BC144C.7070402@dynamicsoft.com> Date: Tue, 01 Jun 2004 01:29:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> In-Reply-To: <40B6886C.5090208@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Jonathan, > > I'm having misgivings about this change now. Devices have somehow become > 2nd class citizens. Thats a fair characterization. > Representing location information now becomes > incredibly complicated. Either you have to replicate it in each service > that shares the device, or as you suggested to me, you put it in one > service tuple and cross reference it from others. But the latter makes a > mess of filtering - what if I filter out the tuple that holds the device > attributes and keep the one that cross references them? A better solution would be to define as a peer of tuple. PIDF allows the document to have things besides tuples. So, we could add and then have each (which represent services) refer to that . I think this would work well with filtering. > > You say that a device has an address, a service doesn't. But from a > practical perspective, a service that is hosted on only one device has a > location too - it is only distributed services that don't have well > defined locations. In the case you are talking about, its still the device that has the property of location; its just that the device happens to host a single service. Whether or not a service is hosted on one device or many doesnt change the fact that location is a fundamental property of a device. > > If you want to make this kind of distinction, then I think we must still > have both device and service tuples, with cross references between them. > And while we are at it, it would then be convenient to permit a single > tuple to represent both when they are 1:1. I think that introducing more options on how to represent things will only further worsen our current situation. Then, service tuples would > have contacts while device tuples wouldn't. And a device tuple would > have a location while a service tuple doesn't. But a device with only > one service can be represented with a combined tuple that both a contact > and a location. This is not far from what I am proposing above, excepting I'm using an explicitly named element and not introducing the special case for 1-1 mappings. We've already said that contact-less tuples are presentities/in-person. How would we differentiate that from device? 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-bounces@ietf.org Tue Jun 1 04:35:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05961 for ; Tue, 1 Jun 2004 04:35:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV4ji-0003G9-Ub for simple-archive@ietf.org; Tue, 01 Jun 2004 04:35:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV4iX-0002kc-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 04:33:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV4ha-0001p8-00; Tue, 01 Jun 2004 04:32:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4a8-00020R-A3; Tue, 01 Jun 2004 04:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4V6-0000LL-Tr for simple@megatron.ietf.org; Tue, 01 Jun 2004 04:20: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 EAA04844 for ; Tue, 1 Jun 2004 04:19:44 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV4Up-00045v-Jd for simple@ietf.org; Tue, 01 Jun 2004 04:19:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV4St-0002o6-00 for simple@ietf.org; Tue, 01 Jun 2004 04:17:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BV4QZ-00025V-00 for simple@ietf.org; Tue, 01 Jun 2004 04:15:19 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i518AFE05195; Tue, 1 Jun 2004 11:10:15 +0300 (EET DST) X-Scanned: Tue, 1 Jun 2004 11:09:46 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5189klV030449; Tue, 1 Jun 2004 11:09:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00N0ZIJV; Tue, 01 Jun 2004 11:09:46 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5189dH22665; Tue, 1 Jun 2004 11:09:39 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Jun 2004 11:09:07 +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] RPID: what does tuple-type really mean? Date: Tue, 1 Jun 2004 11:09:07 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797BA4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RPID: what does tuple-type really mean? Thread-Index: AcRHm8nzVLoom2FZTKCP2Q5+wjM5QgADQ4Mw To: , X-OriginalArrivalTime: 01 Jun 2004 08:09:07.0861 (UTC) FILETIME=[B66C3450:01C447AF] Content-Transfer-Encoding: quoted-printable Cc: hgs@cs.columbia.edu, simple@ietf.org, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Some comments inline > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 01.June.2004 08:30 > To: Paul Kyzivat > Cc: Simple WG; Niemi Aki (Nokia-M/Espoo); Henning Schulzrinne > Subject: Re: [Simple] RPID: what does tuple-type really mean? >=20 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > Jonathan, > >=20 > > I'm having misgivings about this change now. Devices have=20 > somehow become=20 > > 2nd class citizens. >=20 > Thats a fair characterization. >=20 > > Representing location information now becomes=20 > > incredibly complicated. Either you have to replicate it in=20 > each service=20 > > that shares the device, or as you suggested to me, you put=20 > it in one=20 > > service tuple and cross reference it from others. But the=20 > latter makes a=20 > > mess of filtering - what if I filter out the tuple that=20 > holds the device=20 > > attributes and keep the one that cross references them? >=20 > A better solution would be to define as a peer of=20 > tuple. PIDF=20 > allows the document to have things besides tuples. So, we could add=20 > and then have each (which represent=20 > services) refer to=20 > that . I think this would work well with filtering. I don't see a big deal in duplicating location information here (for = simplicity), but if it is for some, then what would be the properties = (attributes and sub-elements) of the element under the root = element? For filtering, we can either say that anything that is cross referenced = is also selected by a filter that selects the element that is cross = referencing, or mandate that a filter must explicitly select the = elements. I prefer the former. >=20 > >=20 > > You say that a device has an address, a service doesn't. But from a=20 > > practical perspective, a service that is hosted on only one=20 > device has a=20 > > location too - it is only distributed services that don't have well=20 > > defined locations. >=20 > In the case you are talking about, its still the device that has the=20 > property of location; its just that the device happens to=20 > host a single=20 > service. Whether or not a service is hosted on one device or=20 > many doesnt=20 > change the fact that location is a fundamental property of a device. Agreed. >=20 > >=20 > > If you want to make this kind of distinction, then I think=20 > we must still=20 > > have both device and service tuples, with cross references=20 > between them.=20 > > And while we are at it, it would then be convenient to=20 > permit a single=20 > > tuple to represent both when they are 1:1. >=20 > I think that introducing more options on how to represent things will=20 > only further worsen our current situation. I agree with Jonathan here and vote for service tuples with = elements inside, and forbidding the converse. I'm on the fence on cross = referencing a element that is directly under the root element. = Are there any other properties of a device that needs to be shared = amongst service tuples besides location information? If so, then it = might be worth while cross referencing. Regards, Hisham >=20 > Then, service tuples would > > have contacts while device tuples wouldn't. And a device=20 > tuple would=20 > > have a location while a service tuple doesn't. But a device=20 > with only=20 > > one service can be represented with a combined tuple that=20 > both a contact=20 > > and a location. >=20 > This is not far from what I am proposing above, excepting I'm=20 > using an=20 > explicitly named element and not introducing the=20 > special case=20 > for 1-1 mappings. We've already said that contact-less tuples are=20 > presentities/in-person. How would we differentiate that from device? >=20 > Thanks, > Jonathan R. > --=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 > _______________________________________________ > 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 mailman-bounces@ietf.org Tue Jun 1 07:10:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17177 for ; Tue, 1 Jun 2004 07:10:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV7AM-00034V-3P for simple-archive@ietf.org; Tue, 01 Jun 2004 07:10:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV79M-0002dN-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 07:09:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV78L-0001nA-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 07:08:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5Tp-0001jJ-Ky for simple-archive@ietf.org; Tue, 01 Jun 2004 05:22:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: simple-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:03:53 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From mailman-admin@ietf.org Tue Jun 1 11:09:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13140 for ; Tue, 1 Jun 2004 11:09:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVAtD-00004N-Ac for simple-archive@ietf.org; Tue, 01 Jun 2004 11:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVAs0-0007B2-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 11:08:04 -0400 Received: from jupiter.cnri.reston.va.us ([132.151.1.18] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BVAqG-0006ET-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 11:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV91P-0005u5-Fb for simple-archive@ietf.org; Tue, 01 Jun 2004 09:09:39 -0400 Date: Tue, 01 Jun 2004 09:09:39 -0400 Message-ID: <20040601130939.26555.15715.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-bounces@ietf.org Tue Jun 1 22:10:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14305 for ; Tue, 1 Jun 2004 22:10:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVLCx-0007Am-Gi for simple-archive@ietf.org; Tue, 01 Jun 2004 22:10:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVLC2-0006gC-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 22:09:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVLB4-0005fp-00; Tue, 01 Jun 2004 22:08:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVKji-00031U-9W; Tue, 01 Jun 2004 21:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVF4m-00052N-5m for simple@megatron.ietf.org; Tue, 01 Jun 2004 15:37: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 PAA16227 for ; Tue, 1 Jun 2004 15:37:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVF4l-0007W5-09 for simple@ietf.org; Tue, 01 Jun 2004 15:37:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVEir-0002YJ-00 for simple@ietf.org; Tue, 01 Jun 2004 15:14:53 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BVEFV-00050F-00 for simple@ietf.org; Tue, 01 Jun 2004 14:44:33 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i51IiLRK029089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Jun 2004 14:44:22 -0400 (EDT) Message-ID: <40BCCE85.80508@cs.columbia.edu> Date: Tue, 01 Jun 2004 14:44:21 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> In-Reply-To: <40BC12AF.8090608@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.99824, Antispam-Data: 2004.6.1.102168 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > The problem here is that a device can host a multiplicity of services > (my cell phone), each of which may have radically different URI, and > that a device itself is not well described by a single contact address. I've never been particularly enamored with the notion of devices being represented as tuples, in the sense of one device = one tuple. Maybe a better way to look at this is that tuples with contacts are *always* services. From a reachability perspective, as to whether I have three plastic gadgets on my belt connected by BlueTooth, or whether they are all in a single Treo-like device or whether they all have a separate network interfaces seems to matter very little, particularly since (as was discussed in the interim) it's hard to make very clear delineations as to what counts as a single device. The only reason I can see that the notion of a device matters is to estimate whether two services are pretty much guaranteed to be available at the same time, by the same person. (As opposed to having one service be left on the dresser at home and one carried by the user.) A simple, unique and non-reachable identifier that indicates this reachability and locational unity, as the token, does this. > > However, you say something important in your suggestion, which is > "contact-equipped tuples can be either devices (which also is an > instance of a service)". My proposal for what "device view" means was > that you have a tuple that represents all of the services available on a > particular device, by doing a pivot operation on that device. In that > way, the service tuple "represents" a device, in that I'm trying to have > a single tuple for each device. However, the tuple is still > fundamentally describing a service, NOT a device. We seem to be arriving at similar conclusions through slightly different paths. My disagreement is that I don't see the possibility of having a single tuple represent all services on a device, given that, as you say, they may not have a single reachable protocol URI (sip, mailto, etc.) that can represent them all. I don't see how urn:device:1234566 helps any, unless we assume that there is a URN resolution mechanism that actually translates this, ENUM-style, into a set of services. > >> >> Both (1) and (2) can contain RPID and CIPID information (the latter >> probably only for tuples). If (2) contains RPID >> information, it means that it refers to the device or service. > > > Which? What would it mean when I have devices that support multiple > services, and a multiplicity of services that can run on a single device? I'd like to determine first what the notion of device is meant to do. The presence of RPID by itself wouldn't be able to distinguish a service from a device, thus, it could appear in tuples of both types. For a service, it could happen that all instances (devices) providing the service have the same RPID information. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 1 22:22:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15205 for ; Tue, 1 Jun 2004 22:22:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVLOo-0005RC-9o for simple-archive@ietf.org; Tue, 01 Jun 2004 22:22:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVLN6-0004SV-00 for simple-archive@ietf.org; Tue, 01 Jun 2004 22:20:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVLLB-00039W-00; Tue, 01 Jun 2004 22:18:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVKjp-00038y-Td; Tue, 01 Jun 2004 21:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVFDB-000702-Hl for simple@megatron.ietf.org; Tue, 01 Jun 2004 15:46: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 PAA17533 for ; Tue, 1 Jun 2004 15:46:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVFD9-00013g-QL for simple@ietf.org; Tue, 01 Jun 2004 15:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVEzq-0005tm-00 for simple@ietf.org; Tue, 01 Jun 2004 15:32:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BVEa7-0000pS-00 for simple@ietf.org; Tue, 01 Jun 2004 15:05:51 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BVEa9-0003NA-CN for simple@ietf.org; Tue, 01 Jun 2004 15:05:53 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i51IviRK029734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Jun 2004 14:57:45 -0400 (EDT) Message-ID: <40BCD1A8.5000200@cs.columbia.edu> Date: Tue, 01 Jun 2004 14:57:44 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <2038BCC78B1AD641891A0D1AE133DBB701797BA4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797BA4@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.99824, Antispam-Data: 2004.6.1.102168 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='SUPERLONG_LINE 0.003, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, __NEW_DOMAIN_EXTENSIONS_2 0, EMAIL_ATTRIBUTION 0, __MOZILLA_MSGID 0, __MIME_TEXT_ONLY 0, HTML_TAG_UNKNOWN 0.000, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, pkyzivat@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit It might help to provide some examples for concreteness. Am I correct that there are two proposals on the table: Proposal 1 - tuples only, with label to hint at spatial correlation: sip:alice@laptop.my-domain.com 17 123 Main Street (laptop, running some SIP client) h323:@laptop.my-domain.com 123 Main Street 17 (same laptop, running NetMeeting) sip:alice@voice-provider.com 5 Elm Street (home) 42 sip:alice@unified.com (my proxy that hides all services; location could be either Elm or Main) This seems pretty clear. If I dial the h323 URL, I can be pretty sure that I reach Alice at her Main Street location. The only drawback is that location information is replicated across tuples. The other model would be similar, except that we pull out the location information into a element: 123 Main hisham.khartabil@nokia.com wrote: > Some comments inline > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Jonathan Rosenberg >>Sent: 01.June.2004 08:30 >>To: Paul Kyzivat >>Cc: Simple WG; Niemi Aki (Nokia-M/Espoo); Henning Schulzrinne >>Subject: Re: [Simple] RPID: what does tuple-type really mean? >> >> >> >> >>Paul Kyzivat wrote: >> >> >>>Jonathan, >>> >>>I'm having misgivings about this change now. Devices have >> >>somehow become >> >>>2nd class citizens. >> >>Thats a fair characterization. >> >> >>>Representing location information now becomes >>>incredibly complicated. Either you have to replicate it in >> >>each service >> >>>that shares the device, or as you suggested to me, you put >> >>it in one >> >>>service tuple and cross reference it from others. But the >> >>latter makes a >> >>>mess of filtering - what if I filter out the tuple that >> >>holds the device >> >>>attributes and keep the one that cross references them? >> >>A better solution would be to define as a peer of >>tuple. PIDF >>allows the document to have things besides tuples. So, we could add >> and then have each (which represent >>services) refer to >>that . I think this would work well with filtering. > > > > I don't see a big deal in duplicating location information here (for simplicity), but if it is for some, then what would be the properties (attributes and sub-elements) of the element under the root element? > > For filtering, we can either say that anything that is cross referenced is also selected by a filter that selects the element that is cross referencing, or mandate that a filter must explicitly select the elements. I prefer the former. > > >>>You say that a device has an address, a service doesn't. But from a >>>practical perspective, a service that is hosted on only one >> >>device has a >> >>>location too - it is only distributed services that don't have well >>>defined locations. >> >>In the case you are talking about, its still the device that has the >>property of location; its just that the device happens to >>host a single >>service. Whether or not a service is hosted on one device or >>many doesnt >>change the fact that location is a fundamental property of a device. > > > Agreed. > > >>>If you want to make this kind of distinction, then I think >> >>we must still >> >>>have both device and service tuples, with cross references >> >>between them. >> >>>And while we are at it, it would then be convenient to >> >>permit a single >> >>>tuple to represent both when they are 1:1. >> >>I think that introducing more options on how to represent things will >>only further worsen our current situation. > > > I agree with Jonathan here and vote for service tuples with elements inside, and forbidding the converse. I'm on the fence on cross referencing a element that is directly under the root element. Are there any other properties of a device that needs to be shared amongst service tuples besides location information? If so, then it might be worth while cross referencing. > > Regards, > Hisham > > >> Then, service tuples would >> >>>have contacts while device tuples wouldn't. And a device >> >>tuple would >> >>>have a location while a service tuple doesn't. But a device >> >>with only >> >>>one service can be represented with a combined tuple that >> >>both a contact >> >>>and a location. >> >>This is not far from what I am proposing above, excepting I'm >>using an >>explicitly named element and not introducing the >>special case >>for 1-1 mappings. We've already said that contact-less tuples are >>presentities/in-person. How would we differentiate that from device? >> >>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-bounces@ietf.org Wed Jun 2 04:35:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07945 for ; Wed, 2 Jun 2004 04:35:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVRE5-00019L-Fw for simple-archive@ietf.org; Wed, 02 Jun 2004 04:35:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVRD7-0000ca-00 for simple-archive@ietf.org; Wed, 02 Jun 2004 04:34:57 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVRC2-0007Os-00; Wed, 02 Jun 2004 04:33:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVQAz-0001rP-6g; Wed, 02 Jun 2004 03:28:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPvk-00030o-Lo for simple@megatron.ietf.org; Wed, 02 Jun 2004 03:12: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 DAA04216 for ; Wed, 2 Jun 2004 03:12:40 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPvT-0005yS-BZ for simple@ietf.org; Wed, 02 Jun 2004 03:12:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVPuW-0005Tf-00 for simple@ietf.org; Wed, 02 Jun 2004 03:11:41 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BVPtW-0004xN-00 for simple@ietf.org; Wed, 02 Jun 2004 03:10:38 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i527AYv10720; Wed, 2 Jun 2004 10:10:35 +0300 (EET DST) X-Scanned: Wed, 2 Jun 2004 10:10:22 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i527AMhr031433; Wed, 2 Jun 2004 10:10:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 003omNbn; Wed, 02 Jun 2004 10:10:20 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5279vH16998; Wed, 2 Jun 2004 10:09:57 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Jun 2004 10:09:41 +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 Date: Wed, 2 Jun 2004 10:09:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797BB3@esebe019.ntc.nokia.com> Thread-Topic: poll for IPR notification impact on iscomposing Thread-Index: AcRCd7YUM0ulYulaS66YQOKNV6XchgF+HlsA To: , X-OriginalArrivalTime: 02 Jun 2004 07:09:41.0214 (UTC) FILETIME=[92F2CFE0:01C44870] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: poll for IPR notification impact on iscomposing X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable folks, We really need to know if the IPR claim on isComposing really bothers = you and affects your implementation. We have so far received very few = comments on this issue. Please let the chairs know. Thanks, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 25.May.2004 19:42 > To: simple@ietf.org > Cc: rsparks@dynamicsoft.com; Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: poll for IPR notification impact on iscomposing >=20 >=20 > draft-ietf-simple-iscomposing-01.txt has completed WGLC and is > being processed for submission to the IESG. >=20 > The IETF has received notification of IPR affecting this document. >=20 > Please see > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-simple-i scomposing.txt Does the presence of this IPR claim and proposed licensing affect the working group's decision to submit this document? If you are planning to implement this standard, will you choose not to because of this = claim? Please provide comments to the list or privately to the=20 chairs no later than Friday Jun 4. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 2 18:43:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29170 for ; Wed, 2 Jun 2004 18:43:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVeSA-0001PQ-2j for simple-archive@ietf.org; Wed, 02 Jun 2004 18:43:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVeRO-00010p-00 for simple-archive@ietf.org; Wed, 02 Jun 2004 18:42:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVeQc-0000In-00; Wed, 02 Jun 2004 18:41:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVaIL-00029u-UA; Wed, 02 Jun 2004 14:16:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVXxO-0005mQ-VJ for simple@megatron.ietf.org; Wed, 02 Jun 2004 11:47: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 LAA29332 for ; Wed, 2 Jun 2004 11:47:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVXxO-0003ab-1f for simple@ietf.org; Wed, 02 Jun 2004 11:47:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVXwX-00036K-00 for simple@ietf.org; Wed, 02 Jun 2004 11:46:18 -0400 Received: from viap106.atea.be ([194.78.143.106] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1BVXvo-0002ZG-00 for simple@ietf.org; Wed, 02 Jun 2004 11:45:32 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JMT27VNJ; Wed, 2 Jun 2004 17:45:01 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jun 2004 17:45:01 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A428890B1E280F@hrtades2.atea.be> From: Biot Olivier To: "'Markus.Isomaki@nokia.com'" Subject: RE: [Simple] New version of XCAP PIDF manipulation draft [nits] Date: Wed, 2 Jun 2004 17:44:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello Markus, Some nits I found so far: Throughout the document AUID is being defined as Application ***Unique*** ID while XCAP defines it as Application ***Usage*** ID. It is obvious from the XCAP spec that the AUIDs ought to be unique. 1. Last paragraph before section 2: XCAP requires application usages to standardize several pieces of information, including an application unique ID (AUID), and an XML schema for the manipulated data. These are specified starting from the Section 4. => Replace with: XCAP requires application usages to standardize several pieces of information, including a unique application usage ID (AUID), and an XML schema for the manipulated data. These are specified starting from Section 4. 2. Header of section 3 4. Application Unique ID => Replace with: 4. Application Usage ID Then another 2 nits in section 12 (1st sentence of each paragraph): Presence document may contain information that is highly sensitive. [...] XCAP base specification mandates that all XCAP servers MUST implement => Replace with: A presence document may contain information that is highly sensitive. [...] The XCAP base specification mandates that all XCAP servers MUST implement Finally the XCAP reference [2] still refers to draft-rosenberg-simple-xcap-02 although that draft is now draft-ietf-simple-xcap-02. Regards, Olivier Biot |-----Original Message----- |From: Markus Isomaki | | |Hi, | |Just to note that a new version of XCAP usage for manipulating |presence document contents has been available for a while, see: |http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf |-manipulation-usage-00.txt | |The main difference to the previous version |(draft-isomaki-...) is that there is more clarifying text on |the relationship of this spec and SIP PUBLISH (in Chapter 3), |and also the security considerations has been updated. | |Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 3 01:58:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26930 for ; Thu, 3 Jun 2004 01:58:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVlFf-0005MT-Gr for simple-archive@ietf.org; Thu, 03 Jun 2004 01:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVlER-0004jT-00 for simple-archive@ietf.org; Thu, 03 Jun 2004 01:57:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVlCt-0003pZ-00; Thu, 03 Jun 2004 01:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BViSi-0006GO-CQ; Wed, 02 Jun 2004 23:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVcB4-0008R3-JY; Wed, 02 Jun 2004 16:17:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16535; Wed, 2 Jun 2004 16:17:17 -0400 (EDT) Message-Id: <200406022017.QAA16535@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 02 Jun 2004 16:17:17 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-iscomposing-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Indication of Message Composition for Instant Messaging Author(s) : H. Schulzrinne Filename : draft-ietf-simple-iscomposing-02.txt Pages : 13 Date : 2004-6-2 In instant messaging (IM) systems, it is useful to know during an IM conversation that the other party is composing a message, e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iscomposing-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-iscomposing-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: <2004-6-2163036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-iscomposing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-iscomposing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-2163036.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Jun 3 10:57:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17625 for ; Thu, 3 Jun 2004 10:57:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVtf0-00034i-Gl for simple-archive@ietf.org; Thu, 03 Jun 2004 10:57:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVtdS-0002aX-00 for simple-archive@ietf.org; Thu, 03 Jun 2004 10:56:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVtcf-0001yg-00; Thu, 03 Jun 2004 10:55:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVsmO-0004yE-Ai; Thu, 03 Jun 2004 10:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVrYw-0006I3-85 for simple@megatron.ietf.org; Thu, 03 Jun 2004 08:43: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 IAA06937 for ; Thu, 3 Jun 2004 08:42:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVrYg-0000aB-Ct for simple@ietf.org; Thu, 03 Jun 2004 08:42:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVrXu-00008j-00 for simple@ietf.org; Thu, 03 Jun 2004 08:42:12 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BVrVv-000738-00 for simple@ietf.org; Thu, 03 Jun 2004 08:40:08 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i53Ce5v28797; Thu, 3 Jun 2004 15:40:05 +0300 (EET DST) X-Scanned: Thu, 3 Jun 2004 15:38:30 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i53CcURA019732; Thu, 3 Jun 2004 15:38:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00uFTo8v; Thu, 03 Jun 2004 15:38:29 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i53CcHH24092; Thu, 3 Jun 2004 15:38:17 +0300 (EET DST) Received: from [172.21.11.223] ([172.21.11.223]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Jun 2004 15:38:03 +0300 Message-ID: <40BF1BAA.7030900@nokia.com> Date: Thu, 03 Jun 2004 15:38:02 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: ext Ben Campbell Subject: Re: [Simple] Details on MSRP Details (DSN) References: <40AE749A.8020505@dynamicsoft.com> <40AE7532.1020209@dynamicsoft.com> In-Reply-To: <40AE7532.1020209@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 12:38:03.0378 (UTC) FILETIME=[9CC43520:01C44967] Content-Transfer-Encoding: 7bit Cc: Eric Burger , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, I think I agree with Eric here. It seems DSN is a very heavy duty tool for doing a simple thing, namely respond e2e with an error if things don't go as planned, or with a success if things went right. The fact that you have to bury this status code inside a DSN does not change the fact that it is an error response. Why do I have to implement yet another RFC to do this? Making DSNs optional is also a bit weird. If you really don't care what happens to your SEND, then drop the transaction state as soon as you get any response from any upstream node. The other end may still send the final reports, but they will simply be dropped to the floor. So, my proposal for how I think the transactions should work in MSRP with or without relays is that every request gets an end-to-end acknowledgement in the form of an MSRP response. In addition, relays may choose to send provisional responses to tell the downstream node that a message was received and is being sent onwards. Sort of like: A R1 R2 B | | | | |-----SEND------>| | | | | | | |<--100 Progress-| | | | |----SEND----->| | | | | | | |<--100 Prog.--| | | | |----SEND------->| | | | | | | |<---200 OK -----| | |<---200 OK ---| | |<---200 OK -----| | | | | | | To me it looks pretty much exactly like it is currently defined in MSRP, but without having to introduce the DSNs etc. The important property however is that you have one way and one way only to respond end-to-end (that is, using response codes > 199). If you take the relays out of the picture, everyting stays exactly the same, except that the sender only gets final responses and no intermediate ones. A relay that chooses not to take on any state maintenance whatsoever, will simply forward data back and forth, and not indicate its existence with a 1xx. However, if it chooses to re-chunk or something, it will need to respond back with occasional 100s, and in case the upstream fails, generate a 4xx. Thoughts? Cheers, Aki ext Ben Campbell wrote: > Oops, itchy trigger finger. I meant to say that, with relays, you either > need to make an upstream transaction pend on a downstream transaction, > which has nasty chaining properties; or you need some way for a relay to > tell you that it could not deliver the message. > > Ben Campbell wrote: > >> Eric Burger wrote: >> >>> I am back after a hiatus. >>> >>> I have not read the latest message-sessions draft. However, I have read >>> some discussions on the list about it. >>> >>> One substantive issue: The status code is NOT a parsing of the three >>> digits >>> of HTTP/SIP. The first digit does map directly. However, the other >>> segments are 3-digit sequences conveying much more detailed status >>> information. >>> >>> >>> A bigger issue comes out when you read the discussions on DSN, >>> fragments, >>> SAR, message size, etc. From a big picture, a high-level description of >>> MSRP is... "We have invented TCP, and it runs over TCP." >>> >>> What triggered this thought? The idea of tossing DSN's after a session >>> completes. This brings us right back to where we started: DSN's DO >>> NOT MAKE >>> SENSE FOR SESSION MODE TRANSACTIONS. They make sense for >>> store-and-forward, >>> but they do not for interactive sessions. We have Layer 8 (user) >>> protocols >>> to deal with it, e.g., "did you get my message?". >> >> >> >> I agree they don't make sense for peer to peer sessions. That is why >> we want them to be optional. Further, it may make sense to make the >> default be no DSN at all, at least for peer to peer sessions. >> >> But when you introduce relays, the fact that you successfully >> delivered a message to the relay does not mean the relay can >> successfully deliver it downstream. This means you either have to make >> the upstre >> >> >>> >>> If the counter-argument is, "what if they didn't read it", then I would >>> suggest sending a registered letter. But seriously, I didn't know that >>> replacing SMTP was in the charter. >>> >>> -- >>> - Eric >>> >>> P.S. Unfortunately, I will not be attending the f2f, so don't hold back >>> responses - either privately or on the list. >>> >>> _______________________________________________ >>> 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-bounces@ietf.org Thu Jun 3 15:54:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08674 for ; Thu, 3 Jun 2004 15:54:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVyId-0007E6-Hw for simple-archive@ietf.org; Thu, 03 Jun 2004 15:54:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVyHa-0006mM-00 for simple-archive@ietf.org; Thu, 03 Jun 2004 15:53:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVyGX-0005yV-00; Thu, 03 Jun 2004 15:52:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVxYQ-00079e-5P; Thu, 03 Jun 2004 15:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVx51-0001Y2-H3 for simple@megatron.ietf.org; Thu, 03 Jun 2004 14:36: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 OAA01393 for ; Thu, 3 Jun 2004 14:36:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVx50-0006X8-Je for simple@ietf.org; Thu, 03 Jun 2004 14:36:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVx2q-00063p-00 for simple@ietf.org; Thu, 03 Jun 2004 14:34:58 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BVx0D-00050J-00 for simple@ietf.org; Thu, 03 Jun 2004 14:31:45 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i53IVBLp026525; Thu, 3 Jun 2004 13:31:11 -0500 Message-ID: <40BF6E6B.9050001@dynamicsoft.com> Date: Thu, 03 Jun 2004 13:31:07 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Details on MSRP Details (DSN) References: <40AE749A.8020505@dynamicsoft.com> <40AE7532.1020209@dynamicsoft.com> <40BF1BAA.7030900@nokia.com> In-Reply-To: <40BF1BAA.7030900@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Eric Burger , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > All, > > I think I agree with Eric here. It seems DSN is a very heavy duty tool > for doing a simple thing, namely respond e2e with an error if things > don't go as planned, or with a success if things went right. The fact > that you have to bury this status code inside a DSN does not change the > fact that it is an error response. Why do I have to implement yet > another RFC to do this? I am open to the suggestion that we don't really need the DSN payload format. It may be enough to have a couple of headers to carry status and correlation info. > > Making DSNs optional is also a bit weird. If you really don't care what > happens to your SEND, then drop the transaction state as soon as you get > any response from any upstream node. The other end may still send the > final reports, but they will simply be dropped to the floor. > The advantage of making dsn optional is the fact that, if the sender chooses to request no DSN, then any relay can _also_ drop state. > So, my proposal for how I think the transactions should work in MSRP > with or without relays is that every request gets an end-to-end > acknowledgement in the form of an MSRP response. In addition, relays may > choose to send provisional responses to tell the downstream node that a > message was received and is being sent onwards. Sort of like: > > A R1 R2 B > | | | | > |-----SEND------>| | | > | | | | > |<--100 Progress-| | | > | |----SEND----->| | > | | | | > | |<--100 Prog.--| | > | | |----SEND------->| > | | | | > | | |<---200 OK -----| > | |<---200 OK ---| | > |<---200 OK -----| | | > | | | | > > To me it looks pretty much exactly like it is currently defined in MSRP, > but without having to introduce the DSNs etc. I don't like the idea of having SEND transactions pend for upstream responses. The point of the DSN model is to say that status reporting between non-adjacent hops is asynchronous. > > The important property however is that you have one way and one way only > to respond end-to-end (that is, using response codes > 199). If you take > the relays out of the picture, everyting stays exactly the same, except > that the sender only gets final responses and no intermediate ones. > > A relay that chooses not to take on any state maintenance whatsoever, > will simply forward data back and forth, and not indicate its existence > with a 1xx. However, if it chooses to re-chunk or something, it will > need to respond back with occasional 100s, and in case the upstream > fails, generate a 4xx. That approach does not seem to me to be better or worse than the MSRP approach discussed in Boston--just different. > > Thoughts? > > Cheers, > Aki > > ext Ben Campbell wrote: > >> Oops, itchy trigger finger. I meant to say that, with relays, you >> either need to make an upstream transaction pend on a downstream >> transaction, which has nasty chaining properties; or you need some way >> for a relay to tell you that it could not deliver the message. >> >> Ben Campbell wrote: >> >>> Eric Burger wrote: >>> >>>> I am back after a hiatus. >>>> >>>> I have not read the latest message-sessions draft. However, I have >>>> read >>>> some discussions on the list about it. >>>> >>>> One substantive issue: The status code is NOT a parsing of the three >>>> digits >>>> of HTTP/SIP. The first digit does map directly. However, the other >>>> segments are 3-digit sequences conveying much more detailed status >>>> information. >>>> >>>> >>>> A bigger issue comes out when you read the discussions on DSN, >>>> fragments, >>>> SAR, message size, etc. From a big picture, a high-level >>>> description of >>>> MSRP is... "We have invented TCP, and it runs over TCP." >>>> >>>> What triggered this thought? The idea of tossing DSN's after a session >>>> completes. This brings us right back to where we started: DSN's DO >>>> NOT MAKE >>>> SENSE FOR SESSION MODE TRANSACTIONS. They make sense for >>>> store-and-forward, >>>> but they do not for interactive sessions. We have Layer 8 (user) >>>> protocols >>>> to deal with it, e.g., "did you get my message?". >>> >>> >>> >>> >>> I agree they don't make sense for peer to peer sessions. That is why >>> we want them to be optional. Further, it may make sense to make the >>> default be no DSN at all, at least for peer to peer sessions. >>> >>> But when you introduce relays, the fact that you successfully >>> delivered a message to the relay does not mean the relay can >>> successfully deliver it downstream. This means you either have to >>> make the upstre >>> >>> >>>> >>>> If the counter-argument is, "what if they didn't read it", then I would >>>> suggest sending a registered letter. But seriously, I didn't know that >>>> replacing SMTP was in the charter. >>>> >>>> -- >>>> - Eric >>>> >>>> P.S. Unfortunately, I will not be attending the f2f, so don't hold back >>>> responses - either privately or on the list. >>>> >>>> _______________________________________________ >>>> 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-bounces@ietf.org Fri Jun 4 04:51:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22355 for ; Fri, 4 Jun 2004 04:51:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWAPv-00003y-Hs for simple-archive@ietf.org; Fri, 04 Jun 2004 04:51:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWAOt-0007T3-00 for simple-archive@ietf.org; Fri, 04 Jun 2004 04:50:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BWAOA-00075T-00; Fri, 04 Jun 2004 04:49:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWAH9-0006I5-G6; Fri, 04 Jun 2004 04:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWACD-0005Gy-CB for simple@megatron.ietf.org; Fri, 04 Jun 2004 04:37: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 EAA21651 for ; Fri, 4 Jun 2004 04:36:59 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWACB-0002PW-5G for simple@ietf.org; Fri, 04 Jun 2004 04:36:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWABC-00022Y-00 for simple@ietf.org; Fri, 04 Jun 2004 04:35:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BWAAb-0001gv-00 for simple@ietf.org; Fri, 04 Jun 2004 04:35:26 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i548ZFv24718; Fri, 4 Jun 2004 11:35:15 +0300 (EET DST) X-Scanned: Fri, 4 Jun 2004 11:35:09 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i548Z9OF025955; Fri, 4 Jun 2004 11:35:09 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00vZB8Qp; Fri, 04 Jun 2004 11:35:07 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i548Z7H20759; Fri, 4 Jun 2004 11:35:07 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Jun 2004 11:35:04 +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] New version of XCAP PIDF manipulation draft [nits] Date: Fri, 4 Jun 2004 11:35:03 +0300 Message-ID: Thread-Topic: [Simple] New version of XCAP PIDF manipulation draft [nits] Thread-Index: AcRI8za7JFbi9mWbTNS6DH+bsFoEGwAs9sPg To: X-OriginalArrivalTime: 04 Jun 2004 08:35:04.0442 (UTC) FILETIME=[D574DDA0:01C44A0E] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Oliver, Thanks a lot for your comments. It's good to have some detailed review = for this draft. Oliver Biot wrote: >=20 > Hello Markus, >=20 > Some nits I found so far: >=20 > Throughout the document AUID is being defined as Application=20 > ***Unique*** ID > while XCAP defines it as Application ***Usage*** ID. It is=20 > obvious from the > XCAP spec that the AUIDs ought to be unique. > You are right. This needs to be corrected. =20 > 1. Last paragraph before section 2: >=20 > XCAP requires application usages to standardize several pieces of > information, including an application unique ID (AUID), and an XML > schema for the manipulated data. These are specified starting from > the Section 4. >=20 > =3D> Replace with: >=20 > XCAP requires application usages to standardize several pieces of > information, including a unique application usage ID (AUID), and > an XML schema for the manipulated data. These are specified > starting from Section 4. >=20 OK. > 2. Header of section 3 >=20 > 4. Application Unique ID >=20 > =3D> Replace with: >=20 > 4. Application Usage ID >=20 OK. >=20 > Then another 2 nits in section 12 (1st sentence of each paragraph): >=20 > Presence document may contain information that is=20 > highly sensitive. > [...] > XCAP base specification mandates that all XCAP servers MUST > implement >=20 > =3D> Replace with: >=20 > A presence document may contain information that is highly > sensitive. > [...] > The XCAP base specification mandates that all XCAP servers MUST > implement >=20 OK. >=20 > Finally the XCAP reference [2] still refers to > draft-rosenberg-simple-xcap-02 although that draft is now > draft-ietf-simple-xcap-02. >=20 OK, this should be changed, although in the final RFC this has to = reference to the eventual XCAP RFC. > Regards, >=20 > Olivier Biot >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 4 08:03:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01637 for ; Fri, 4 Jun 2004 08:03:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWDPi-0001a9-M6 for simple-archive@ietf.org; Fri, 04 Jun 2004 08:03:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWDOi-0001DL-00 for simple-archive@ietf.org; Fri, 04 Jun 2004 08:02:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BWDNs-0000Wv-00; Fri, 04 Jun 2004 08:01:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWDHc-0005HX-Un; Fri, 04 Jun 2004 07:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWDEw-0004wP-VA for simple@megatron.ietf.org; Fri, 04 Jun 2004 07:52: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 HAA01259 for ; Fri, 4 Jun 2004 07:52:02 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWDEw-0005TP-DW for simple@ietf.org; Fri, 04 Jun 2004 07:52:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWDDx-00057W-00 for simple@ietf.org; Fri, 04 Jun 2004 07:51:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BWDCy-0004OJ-00 for simple@ietf.org; Fri, 04 Jun 2004 07:50:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i54BmkE01501; Fri, 4 Jun 2004 14:48:46 +0300 (EET DST) X-Scanned: Fri, 4 Jun 2004 14:48:22 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i54BmMEZ002223; Fri, 4 Jun 2004 14:48:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00TOxEuF; Fri, 04 Jun 2004 14:48:21 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i54Bm8H06478; Fri, 4 Jun 2004 14:48:08 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Jun 2004 14:47:50 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] WGLC: prescaps - WGLC summary Date: Fri, 4 Jun 2004 14:47:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DF95@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: prescaps - WGLC summary Thread-Index: AcQ+lvTWyQHbDZezSYS5xYo/uUQ4DwD10Wvg To: , , X-OriginalArrivalTime: 04 Jun 2004 11:47:50.0005 (UTC) FILETIME=[C311BA50:01C44A29] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Here is a list of issues which have come up during WGLC. If I have missed something please let me know. 1) Change of extensibility mechanism for , , , , , and elements Currently these elements are defined as string type elements (without any restriction in values) or they are defined as enumerated string types. It has been proposed that these elements should be defined using substitutionGroups. This would allow use of XML parsers to check that elements names are correct and that would make better use of XML namespaces. As an example XML for element would look like this: Reason for having and elements instead of supported attribute in each individual element is that I wasn't able to make it work correctly in XML (so that attribute would be inherited to all possible elements that can be used inside ). I will post the new schema into the list as soon as I have it ready. 2) Add more text into element definitions about which values are allowed as element values This is now party handled by the changes in XML schema. I will also add references to IANA registries into appropriate places. 3) Change XML attribute 'negated' to 'supported' Current usage/naming of 'negated' attribute seems be somewhat confusing and will be renamed as 'supported' in the next version. This means 'negated=3Dfalse' =3D> 'supported=3Dtrue' and 'negated=3Dtrue' =3D> 'supported=3Dfalse'. 4) Remove duplicate normative statements Current document contains few normative statements which are specified both in XML schema and in document as normative statements. In these cases I will remove normative text from document text and will use XML schema as only normative statement.=20 5) Change of namespace identifier Current draft defines XML namespace identifier as: urn:ietf:params:xml:ns:simple-prescaps-ext. As the extension should be used under element correct namespace is probably urn:ietf:params:xml:ns:pidf:status:prescaps. 6) NIT fixes I have received some number of nits which will be fixed. - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 4 11:02:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15641 for ; Fri, 4 Jun 2004 11:02:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWGDT-0005s0-Uc for simple-archive@ietf.org; Fri, 04 Jun 2004 11:02:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWGCI-0005SW-00 for simple-archive@ietf.org; Fri, 04 Jun 2004 11:01:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BWGBR-0004zK-00; Fri, 04 Jun 2004 11:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWG1T-0003vd-IG; Fri, 04 Jun 2004 10:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWFov-0001d4-DF for simple@megatron.ietf.org; Fri, 04 Jun 2004 10:37: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 KAA14249 for ; Fri, 4 Jun 2004 10:37:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWFou-0004hU-Et for simple@ietf.org; Fri, 04 Jun 2004 10:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWFnq-0004KT-00 for simple@ietf.org; Fri, 04 Jun 2004 10:36:15 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BWFmr-0003xe-00 for simple@ietf.org; Fri, 04 Jun 2004 10:35:13 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i54EYav08726; Fri, 4 Jun 2004 17:34:36 +0300 (EET DST) X-Scanned: Fri, 4 Jun 2004 17:33:56 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i54EXurq007739; Fri, 4 Jun 2004 17:33:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00bQzO2N; Fri, 04 Jun 2004 17:33:54 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i54EXqH08242; Fri, 4 Jun 2004 17:33:52 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Jun 2004 17:33:47 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Jun 2004 17:33:47 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 10.162.253.213 10.162.253.213 via HTTP with MS-WebStorage 6.0.6249 Received: from hed040-210.research.nokia.com by esebe013.ntc.nokia.com; 04 Jun 2004 17:33:47 +0300 Subject: Re: [Simple] Details on MSRP Details (DSN) From: Aki Niemi To: ext Ben Campbell In-Reply-To: <40BF6E6B.9050001@dynamicsoft.com> References: <40AE749A.8020505@dynamicsoft.com> <40AE7532.1020209@dynamicsoft.com> <40BF1BAA.7030900@nokia.com> <40BF6E6B.9050001@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1086359627.31871.70.camel@hed040-210.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Fri, 04 Jun 2004 17:33:47 +0300 X-OriginalArrivalTime: 04 Jun 2004 14:33:47.0017 (UTC) FILETIME=[F1E92F90:01C44A40] Content-Transfer-Encoding: 7bit Cc: Eric Burger , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Inline. On Thu, 2004-06-03 at 21:31, ext Ben Campbell wrote: > Aki Niemi wrote: > > > All, > > > > I think I agree with Eric here. It seems DSN is a very heavy duty tool > > for doing a simple thing, namely respond e2e with an error if things > > don't go as planned, or with a success if things went right. The fact > > that you have to bury this status code inside a DSN does not change the > > fact that it is an error response. Why do I have to implement yet > > another RFC to do this? > > I am open to the suggestion that we don't really need the DSN payload > format. It may be enough to have a couple of headers to carry status and > correlation info. At a minimum, a header and correlating ID in a REPORT would seem like an OK approach. In terms of transaction model, I still don't see what the big difference in that approach would be to the one I outlined in the post. More on this below... > > > > Making DSNs optional is also a bit weird. If you really don't care what > > happens to your SEND, then drop the transaction state as soon as you get > > any response from any upstream node. The other end may still send the > > final reports, but they will simply be dropped to the floor. > > > > The advantage of making dsn optional is the fact that, if the sender > chooses to request no DSN, then any relay can _also_ drop state I'm still confused by something here. So basically we are saying there needs to be two types of messages: SEND, and OPPORTNISTIC-SEND, where with SEND the sender is interested to know what happens to the request thus requiring a response; with OPPORTUNISTIC-SEND the sender simply doesn't care and needs no responses whatsoever. I can't think of a sender who would use OPPORTUNISTIC-SEND in an MSRP session. At least there doesn't seem to be any benefits to using it - only drawbacks (i.e., you don't know even if the other end supported the media type). So in the worst case scenario, relays are never able to work without maintaining the transaction state, if all messages are bound to be SENDs. There is a conflict of interest between the sender and the relays, and I think we really need a way that a relay can choose to be stateless, irrespective of the method. > > So, my proposal for how I think the transactions should work in MSRP > > with or without relays is that every request gets an end-to-end > > acknowledgement in the form of an MSRP response. In addition, relays may > > choose to send provisional responses to tell the downstream node that a > > message was received and is being sent onwards. Sort of like: > > > > A R1 R2 B > > | | | | > > |-----SEND------>| | | > > | | | | > > |<--100 Progress-| | | > > | |----SEND----->| | > > | | | | > > | |<--100 Prog.--| | > > | | |----SEND------->| > > | | | | > > | | |<---200 OK -----| > > | |<---200 OK ---| | > > |<---200 OK -----| | | > > | | | | > > > > To me it looks pretty much exactly like it is currently defined in MSRP, > > but without having to introduce the DSNs etc. > > I don't like the idea of having SEND transactions pend for upstream > responses. That's already what you have with SEND-200OK-REPORT, no? The sender can only discard the transaction state once it gets a success report. > The point of the DSN model is to say that status reporting between > non-adjacent hops is asynchronous. Meaning that not each chunk (SEND transaction) needs a response, but a response is generated only after the full message has been received? So we make it so that a 200 OK is only generated when the all chunks have arrived. Of course, there could be a 4xx even before that, and things would still work, right? > > > > The important property however is that you have one way and one way only > > to respond end-to-end (that is, using response codes > 199). If you take > > the relays out of the picture, everyting stays exactly the same, except > > that the sender only gets final responses and no intermediate ones. > > > > A relay that chooses not to take on any state maintenance whatsoever, > > will simply forward data back and forth, and not indicate its existence > > with a 1xx. However, if it chooses to re-chunk or something, it will > > need to respond back with occasional 100s, and in case the upstream > > fails, generate a 4xx. > > That approach does not seem to me to be better or worse than the MSRP > approach discussed in Boston--just different. I think it is better in that the decision of whether a relay is to take on state maintenance or not is based not on the sender (DSN or no DSN requested), but on the relay's local policy and behavior. Cheers, Aki > > > > Thoughts? > > > > Cheers, > > Aki > > > > ext Ben Campbell wrote: > > > >> Oops, itchy trigger finger. I meant to say that, with relays, you > >> either need to make an upstream transaction pend on a downstream > >> transaction, which has nasty chaining properties; or you need some way > >> for a relay to tell you that it could not deliver the message. > >> > >> Ben Campbell wrote: > >> > >>> Eric Burger wrote: > >>> > >>>> I am back after a hiatus. > >>>> > >>>> I have not read the latest message-sessions draft. However, I have > >>>> read > >>>> some discussions on the list about it. > >>>> > >>>> One substantive issue: The status code is NOT a parsing of the three > >>>> digits > >>>> of HTTP/SIP. The first digit does map directly. However, the other > >>>> segments are 3-digit sequences conveying much more detailed status > >>>> information. > >>>> > >>>> > >>>> A bigger issue comes out when you read the discussions on DSN, > >>>> fragments, > >>>> SAR, message size, etc. From a big picture, a high-level > >>>> description of > >>>> MSRP is... "We have invented TCP, and it runs over TCP." > >>>> > >>>> What triggered this thought? The idea of tossing DSN's after a session > >>>> completes. This brings us right back to where we started: DSN's DO > >>>> NOT MAKE > >>>> SENSE FOR SESSION MODE TRANSACTIONS. They make sense for > >>>> store-and-forward, > >>>> but they do not for interactive sessions. We have Layer 8 (user) > >>>> protocols > >>>> to deal with it, e.g., "did you get my message?". > >>> > >>> > >>> > >>> > >>> I agree they don't make sense for peer to peer sessions. That is why > >>> we want them to be optional. Further, it may make sense to make the > >>> default be no DSN at all, at least for peer to peer sessions. > >>> > >>> But when you introduce relays, the fact that you successfully > >>> delivered a message to the relay does not mean the relay can > >>> successfully deliver it downstream. This means you either have to > >>> make the upstre > >>> > >>> > >>>> > >>>> If the counter-argument is, "what if they didn't read it", then I would > >>>> suggest sending a registered letter. But seriously, I didn't know that > >>>> replacing SMTP was in the charter. > >>>> > >>>> -- > >>>> - Eric > >>>> > >>>> P.S. Unfortunately, I will not be attending the f2f, so don't hold back > >>>> responses - either privately or on the list. > >>>> > >>>> _______________________________________________ > >>>> 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-bounces@ietf.org Fri Jun 4 15:05:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01870 for ; Fri, 4 Jun 2004 15:05:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWK0c-0000PN-Sk for simple-archive@ietf.org; Fri, 04 Jun 2004 15:05:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWJyB-0007AW-00 for simple-archive@ietf.org; Fri, 04 Jun 2004 15:03:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWJut-0006Mb-00; Fri, 04 Jun 2004 14:59:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BWJut-00088s-KQ; Fri, 04 Jun 2004 14:59:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWJnr-00037s-HP; Fri, 04 Jun 2004 14:52:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWJg4-0001JJ-38 for simple@megatron.ietf.org; Fri, 04 Jun 2004 14:44: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 OAA29860 for ; Fri, 4 Jun 2004 14:44:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWJg2-0000wG-TW for simple@ietf.org; Fri, 04 Jun 2004 14:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWJf5-0000bA-00 for simple@ietf.org; Fri, 04 Jun 2004 14:43:28 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BWJeC-0007ji-00 for simple@ietf.org; Fri, 04 Jun 2004 14:42:32 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i54Ig0Lp032171; Fri, 4 Jun 2004 13:42:00 -0500 Message-ID: <40C0C275.1010406@dynamicsoft.com> Date: Fri, 04 Jun 2004 13:41:57 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Details on MSRP Details (DSN) References: <40AE749A.8020505@dynamicsoft.com> <40AE7532.1020209@dynamicsoft.com> <40BF1BAA.7030900@nokia.com> <40BF6E6B.9050001@dynamicsoft.com> <1086359627.31871.70.camel@hed040-210.research.nokia.com> In-Reply-To: <1086359627.31871.70.camel@hed040-210.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Eric Burger , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Aki Niemi wrote: [...] > > I'm still confused by something here. So basically we are saying there > needs to be two types of messages: SEND, and OPPORTNISTIC-SEND, where > with SEND the sender is interested to know what happens to the request > thus requiring a response; with OPPORTUNISTIC-SEND the sender simply > doesn't care and needs no responses whatsoever. > > I can't think of a sender who would use OPPORTUNISTIC-SEND in an MSRP > session. At least there doesn't seem to be any benefits to using it - > only drawbacks (i.e., you don't know even if the other end supported the > media type). I have never said that I think the opportunistic send is a good thing. Other's have stated it as a requirement, which the work group has not overruled so far. > > So in the worst case scenario, relays are never able to work without > maintaining the transaction state, if all messages are bound to be > SENDs. There is a conflict of interest between the sender and the > relays, and I think we really need a way that a relay can choose to be > stateless, irrespective of the method. > It is possible to build a service where a relay rejects messages that do not conform to its reporting policy, as a policy violation. Clients would be free to resend without report requests. I personally would not build a service this way, but others have said that they intend to. [...] >> >>I don't like the idea of having SEND transactions pend for upstream >>responses. > > > That's already what you have with SEND-200OK-REPORT, no? The sender can > only discard the transaction state once it gets a success report. > > Typically, no. This would only be true if you had requested success reports. More typically, the sending client discards state as soon as it sees the 200OK. If they later get a failure report, they simply tell the user they got a failure report. The "report" is an independent transaction from the "send". >>The point of the DSN model is to say that status reporting between >>non-adjacent hops is asynchronous. > > > Meaning that not each chunk (SEND transaction) needs a response, but a > response is generated only after the full message has been received? > > So we make it so that a 200 OK is only generated when the all chunks > have arrived. Of course, there could be a 4xx even before that, and > things would still work, right? > > >>>The important property however is that you have one way and one way only >>>to respond end-to-end (that is, using response codes > 199). If you take >>>the relays out of the picture, everyting stays exactly the same, except >>>that the sender only gets final responses and no intermediate ones. >>> >>>A relay that chooses not to take on any state maintenance whatsoever, >>>will simply forward data back and forth, and not indicate its existence >>>with a 1xx. However, if it chooses to re-chunk or something, it will >>>need to respond back with occasional 100s, and in case the upstream >>>fails, generate a 4xx. >> >>That approach does not seem to me to be better or worse than the MSRP >>approach discussed in Boston--just different. > > > I think it is better in that the decision of whether a relay is to take > on state maintenance or not is based not on the sender (DSN or no DSN > requested), but on the relay's local policy and behavior. > > Cheers, > Aki > > >>>Thoughts? >>> >>>Cheers, >>>Aki >>> >>>ext Ben Campbell wrote: >>> >>> >>>>Oops, itchy trigger finger. I meant to say that, with relays, you >>>>either need to make an upstream transaction pend on a downstream >>>>transaction, which has nasty chaining properties; or you need some way >>>>for a relay to tell you that it could not deliver the message. >>>> >>>>Ben Campbell wrote: >>>> >>>> >>>>>Eric Burger wrote: >>>>> >>>>> >>>>>>I am back after a hiatus. >>>>>> >>>>>>I have not read the latest message-sessions draft. However, I have >>>>>>read >>>>>>some discussions on the list about it. >>>>>> >>>>>>One substantive issue: The status code is NOT a parsing of the three >>>>>>digits >>>>>>of HTTP/SIP. The first digit does map directly. However, the other >>>>>>segments are 3-digit sequences conveying much more detailed status >>>>>>information. >>>>>> >>>>>> >>>>>>A bigger issue comes out when you read the discussions on DSN, >>>>>>fragments, >>>>>>SAR, message size, etc. From a big picture, a high-level >>>>>>description of >>>>>>MSRP is... "We have invented TCP, and it runs over TCP." >>>>>> >>>>>>What triggered this thought? The idea of tossing DSN's after a session >>>>>>completes. This brings us right back to where we started: DSN's DO >>>>>>NOT MAKE >>>>>>SENSE FOR SESSION MODE TRANSACTIONS. They make sense for >>>>>>store-and-forward, >>>>>>but they do not for interactive sessions. We have Layer 8 (user) >>>>>>protocols >>>>>>to deal with it, e.g., "did you get my message?". >>>>> >>>>> >>>>> >>>>> >>>>>I agree they don't make sense for peer to peer sessions. That is why >>>>>we want them to be optional. Further, it may make sense to make the >>>>>default be no DSN at all, at least for peer to peer sessions. >>>>> >>>>>But when you introduce relays, the fact that you successfully >>>>>delivered a message to the relay does not mean the relay can >>>>>successfully deliver it downstream. This means you either have to >>>>>make the upstre >>>>> >>>>> >>>>> >>>>>>If the counter-argument is, "what if they didn't read it", then I would >>>>>>suggest sending a registered letter. But seriously, I didn't know that >>>>>>replacing SMTP was in the charter. >>>>>> >>>>>>-- >>>>>>- Eric >>>>>> >>>>>>P.S. Unfortunately, I will not be attending the f2f, so don't hold back >>>>>>responses - either privately or on the list. >>>>>> >>>>>>_______________________________________________ >>>>>>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-bounces@ietf.org Mon Jun 7 09:59:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16377 for ; Mon, 7 Jun 2004 09:59:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXKeu-0003bX-KG for simple-archive@ietf.org; Mon, 07 Jun 2004 09:59:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXKdp-00037l-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 09:58:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXKce-0002G2-00; Mon, 07 Jun 2004 09:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKQo-0007xL-EQ; Mon, 07 Jun 2004 09:44:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKFg-00051b-9W for simple@megatron.ietf.org; Mon, 07 Jun 2004 09:33: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 JAA14645 for ; Mon, 7 Jun 2004 09:33:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXKFf-0007Y8-JG for simple@ietf.org; Mon, 07 Jun 2004 09:33:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXKEg-00074b-00 for simple@ietf.org; Mon, 07 Jun 2004 09:32:23 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BXKDe-00069t-00 for simple@ietf.org; Mon, 07 Jun 2004 09:31:18 -0400 Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i57DUlXI013087 for ; Mon, 7 Jun 2004 08:30:47 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 08:29:19 -0500 Message-ID: <77BEF8ACD6CB1B4DA605D9D9CF554AEB0350879E@eamrcnt727.exu.ericsson.se> From: "Nilo Mitra (NY/EMX)" To: simple@ietf.org Date: Mon, 7 Jun 2004 08:30:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Simple] A requirement on retrieving "List of Lists" using XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello all: Some of you may know that the Open Mobile Alliance (OMA) is strongly considering using the IETF work on XCAP as the means for a subscriber to access and manage his contact lists, communications groups and other session-related policies. In the course of analysing such requirements, it seems that it would be very useful to support the retrieval of a list of lists (documents) showing the "directory" of the user's various lists (documents). Such situations arise when a user needs to retrieve the data related to his contacts and policies stored in the network because: 1) The user has changed to a different terminal and wants to make the above-mentioned content available on the new terminal, or 2) The user has for some reason deleted the information in the terminal. Therefore, he needs a way of finding what is data is stored in the network and re-populating his terminal with that data. To do the above, the user's terminal needs to be able to fetch the list of his documents available on the XCAP server. However, this support is missing in the current draft of XCAP, draft-ietf-simple-xcap-02.txt. The current specification does not describe how a list of lists shall be handled, as XCAP defines how to store one XML document and how to manipulate it. It does not cover how the user finds the paths to already stored documents. Are there any plans for supporting such a requirement in the next draft of XCAP? In anticipation that you may have already considered such a requirement, here are some additional thoughts on the subject: Because in a deployment it is possible that different network elements can host certain types of list, it seems best from a coordination point of view if there exists one list of list per type of list or service. IOW, there is no need to keep a master list of lists for per-user information in the entire domain. Moreover, it is also likely that there will be terminals that do not support or needs all types of per-user data, particularly if such terminals support applications or services that do not need such data. Thus, it should be possible to only access and retrieve the data that is needed. If we apply this to XCAP, this means that there should be one list of lists per AUID. So one proposal is that XCAP specification defines a way to fetch the list of XML documents stored in a XCAP server. We suggest that the list of lists is returned as a resource list, and that the following method is used: "GET http://xcap.example.com/services//users// HTTP/1.1" to fetch such an XML document. As base for the schema of the XML document the xs:schema targetNamespace = "urn:ietf:params:xml:ns:resource-lists" is proposed, i.e., it is a resource list with XCAP URIs as entries. Thoughts? Comments? Regards, Nilo Nilo Mitra Ericsson, Inc. desk: +1 212 843 8451 mobile: +1 516 476 7427 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 10:15:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17989 for ; Mon, 7 Jun 2004 10:15:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXKuJ-0002z9-H4 for simple-archive@ietf.org; Mon, 07 Jun 2004 10:15:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXKt4-00028Z-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 10:14:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXKrv-0001Wh-00; Mon, 07 Jun 2004 10:12:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKea-0003Wg-D9; Mon, 07 Jun 2004 09:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKZs-000296-7j for simple@megatron.ietf.org; Mon, 07 Jun 2004 09:54: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 JAA15939 for ; Mon, 7 Jun 2004 09:54:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXKZr-0001KS-IJ for simple@ietf.org; Mon, 07 Jun 2004 09:54:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXKYs-0000so-00 for simple@ietf.org; Mon, 07 Jun 2004 09:53:14 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BXKXm-0000Bf-00 for simple@ietf.org; Mon, 07 Jun 2004 09:52:06 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i57Dq3915967; Mon, 7 Jun 2004 15:52:03 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i57Dq2l26490; Mon, 7 Jun 2004 15:52:03 +0200 (MEST) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA19566; Mon, 7 Jun 2004 15:51:15 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 15:52:00 +0200 Message-ID: From: Schmidt Christian To: "'Jonathan Rosenberg'" , simple@ietf.org Date: Mon, 7 Jun 2004 15:51:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Simple] Xcap authorization rules - Multiple URIs in Identity X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jonathan, a short question, concerning the actual Version of your draft: Presence Authorization Rules: draft-ietf-simple-presence-rules-00 Is it possible to use more then one uri in the Identity Element (3.1.1)? Example: user1@example.com user2@example.com This could be very helpful, to increase efficiency (subscription or change of rules). There would be no need for an external reference and the related problems. Is it possible to extend section 3.1.1 of your draft, to make clear, that multiple uri's are allowed? Best Regards, +++++++++++++++++++++++++++++++++++++ + Christian Schmidt, Siemens AG + + Phone +49 89 636-75192 + + Fax +49 89 636-75165 + + Mobile +49 178 7700363 + + christian-schmidt@siemens.com + + schmidt-augsburg@t-online.de + +++++++++++++++++++++++++++++++++++++ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 11:38:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24141 for ; Mon, 7 Jun 2004 11:38:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMCQ-0002R2-Kd for simple-archive@ietf.org; Mon, 07 Jun 2004 11:38:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMAm-0001ix-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 11:36:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXM9W-0000m8-00; Mon, 07 Jun 2004 11:35:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXM7o-000467-1x; Mon, 07 Jun 2004 11:33:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXM1w-0005Rw-KF; Mon, 07 Jun 2004 11:27:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXFpV-0005Qc-Cr for simple@megatron.ietf.org; Mon, 07 Jun 2004 04: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 EAA01885 for ; Mon, 7 Jun 2004 04:50:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXFpS-0004JR-Ve for simple@ietf.org; Mon, 07 Jun 2004 04:50:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXFoY-0003yq-00 for simple@ietf.org; Mon, 07 Jun 2004 04:49:07 -0400 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1BXFnx-0003dD-00 for simple@ietf.org; Mon, 07 Jun 2004 04:48:29 -0400 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] RE: poll for IPR notification impact on iscomposing Date: Mon, 7 Jun 2004 10:47:59 +0200 Message-ID: Thread-Topic: [Simple] RE: poll for IPR notification impact on iscomposing Thread-Index: AcRCd7YUM0ulYulaS66YQOKNV6XchgF+HlsAAP4hqyA= From: "Christian Jansson" To: , , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Jun 2004 11:27:12 -0400 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sorry for the late answer. We are really planning on implementing this kind of functionality if a standard is set on how to do it.=20 > If you are planning to implement this standard, will you choose not to because of this claim? Does the working group actually know about other ways of solving the problem that are not affected by the IPR? In that case it would always be better to choose such solution.=20 But if the working group does not see no such obvious solution (which I assume has been investigated), and given that the IPR licensing cost is reasonable, we will implement the solution, if the group decides that it is the right way to go. / Christian Jansson, Hotsip > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: den 2 juni 2004 09:10 > To: rsparks@dynamicsoft.com; simple@ietf.org > Subject: [Simple] RE: poll for IPR notification impact on iscomposing >=20 >=20 > folks, >=20 > We really need to know if the IPR claim on isComposing really=20 > bothers you and affects your implementation. We have so far=20 > received very few comments on this issue. >=20 > Please let the chairs know. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: 25.May.2004 19:42 > > To: simple@ietf.org > > Cc: rsparks@dynamicsoft.com; Khartabil Hisham=20 > (Nokia-TP-MSW/Helsinki) > > Subject: poll for IPR notification impact on iscomposing > >=20 > >=20 > > draft-ietf-simple-iscomposing-01.txt has completed WGLC and=20 > is being=20 > > processed for submission to the IESG. > >=20 > > The IETF has received notification of IPR affecting this document. > >=20 > > Please see=20 > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-simple-i > scomposing.txt >=20 > Does the presence of this IPR claim and proposed licensing=20 > affect the working group's decision to submit this document?=20 > If you are planning to implement this standard, will you=20 > choose not to because of this claim? >=20 > Please provide comments to the list or privately to the=20 > chairs no later than Friday Jun 4. >=20 > Thanks, > RjS >=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-bounces@ietf.org Mon Jun 7 11:38:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24162 for ; Mon, 7 Jun 2004 11:38:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMCR-0002S1-Tw for simple-archive@ietf.org; Mon, 07 Jun 2004 11:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMAo-0001jD-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 11:36:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXM9W-0000m8-01; Mon, 07 Jun 2004 11:35:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXM71-0003z5-7h; Mon, 07 Jun 2004 11:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXM1w-0005RD-1G; Mon, 07 Jun 2004 11:27:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWKzU-00038O-MG for simple@megatron.ietf.org; Fri, 04 Jun 2004 16:08: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 QAA06722 for ; Fri, 4 Jun 2004 16:08:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWKzS-0007Ma-TT for simple@ietf.org; Fri, 04 Jun 2004 16:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWKyc-00071y-00 for simple@ietf.org; Fri, 04 Jun 2004 16:07:43 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BWKxr-0006eA-00 for simple@ietf.org; Fri, 04 Jun 2004 16:06:55 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i54K6PLc019043 for ; Fri, 4 Jun 2004 15:06:25 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Jun 2004 15:05:26 -0500 Message-ID: <77BEF8ACD6CB1B4DA605D9D9CF554AEB0350876E@eamrcnt727.exu.ericsson.se> From: "Nilo Mitra (NY/EMX)" To: simple@ietf.org Date: Fri, 4 Jun 2004 15:06:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Mailman-Approved-At: Mon, 07 Jun 2004 11:27:13 -0400 Subject: [Simple] A requirement on retrieving "List of Lists" using XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello all: Some of you may know that the Open Mobile Alliance (OMA) is strongly considering using the IETF work on XCAP as the means for a subscriber to access and manage his contact lists, communications groups and other session-related policies. In the course of analysing such requirements, it seems that it would be very useful to support the retrieval of a list of lists (documents) showing the "directory" of the user's various lists (documents). Such situations arise when a user needs to retrieve the data related to his contacts and policies stored in the network because: 1) The user has changed to a different terminal and wants to make the above-mentioned content available on the new terminal, or 2) The user has for some reason deleted the information in the terminal. Therefore, he needs a way of finding what is data is stored in the network and re-populating his terminal with that data. To do the above, the user's terminal needs to be able to fetch the list of his documents available on the XCAP server. However, this support is missing in the current draft of XCAP, draft-ietf-simple-xcap-02.txt. The current specification does not describe how a list of lists shall be handled, as XCAP defines how to store one XML document and how to manipulate it. It does not cover how the user finds the paths to already stored documents. Are there any plans for supporting such a requirement in the next draft of XCAP? In anticipation that you may have already considered such a requirement, here are some additional thoughts on the subject: Because in a deployment it is possible that different network elements can host certain types of list, it seems best from a coordination point of view if there exists one list of list per type of list or service. IOW, there is no need to keep a master list of lists for per-user information in the entire domain. Moreover, it is also likely that there will be terminals that do not support or needs all types of per-user data, particularly if such terminals support applications or services that do not need such data. Thus, it should be possible to only access and retrieve the data that is needed. If we apply this to XCAP, this means that there should be one list of lists per AUID. So one proposal is that XCAP specification defines a way to fetch the list of XML documents stored in a XCAP server. We suggest that the list of lists is returned as a resource list, and that the following method is used: "GET http://xcap.example.com/services//users// HTTP/1.1" to fetch such an XML document. As base for the schema of the XML document the xs:schema targetNamespace = "urn:ietf:params:xml:ns:resource-lists" is proposed, i.e., it is a resource list with XCAP URIs as entries. Thoughts? Comments? Regards, Nilo Nilo Mitra Ericsson, Inc. desk: +1 212 843 8451 mobile: +1 516 476 7427 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 11:38:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24197 for ; Mon, 7 Jun 2004 11:38:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMCW-0002Wi-ID for simple-archive@ietf.org; Mon, 07 Jun 2004 11:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMAu-0001k7-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 11:36:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXM9Y-0000m8-01; Mon, 07 Jun 2004 11:35:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXM5J-0003ri-Js; Mon, 07 Jun 2004 11:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXLxN-0004SC-0c; Mon, 07 Jun 2004 11:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTajY-0004Wh-PU for simple@megatron.ietf.org; Fri, 28 May 2004 02:20: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 CAA06156 for ; Fri, 28 May 2004 02:20:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTajH-00068b-Bz for simple@ietf.org; Fri, 28 May 2004 02:20:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTaim-0005ok-00 for simple@ietf.org; Fri, 28 May 2004 02:20:00 -0400 Received: from c24375.rim.net ([216.9.243.75] helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1BTahV-0005Ac-00 for simple@ietf.org; Fri, 28 May 2004 02:18:41 -0400 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id A1301B4C96 for ; Fri, 28 May 2004 02:17:58 -0400 (EDT) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2004052802175707791 ; Fri, 28 May 2004 02:17:57 -0400 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 May 2004 02:17:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: DSN lifetime open issue Date: Fri, 28 May 2004 02:17:57 -0400 Message-ID: Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcREBNpGT+a0nu+bQYCy8DfvTRWA7AAdqqX2 From: "Andrew Allen" To: , X-OriginalArrivalTime: 28 May 2004 06:17:58.0565 (UTC) FILETIME=[858F6550:01C4447B] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Jun 2004 11:22:07 -0400 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable MSRP and SIP Message method are not inherrently store and forward like = SMS and MMS. This is recognised by 3GPP (the body that produces specifcations for GSM = and UMTS) who have defined SIP message method as immediate messaging and = MSRP as session-based messaging wheras SMS, MMS and email are in another = category - deferred messaging.=20 SIP message method could be stored by an application server and = forwarded later as could MSRP - but in their basic operation the are = end-end message primitives and not a store and forward service like SMS -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 European Mobile +358 50 467 5870 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld -----Original Message----- From: simple-bounces@ietf.org To: SIMPLE WG Sent: Thu May 27 11:19:01 2004 Subject: RE: [Simple] MSRP: DSN lifetime open issue [snip] All, Just to give an example, London has a "Congestion Charge" which is a = fixed fee, payable per day I drive into London (never in my case) charge. = This can be paid by sending an SMS message to the "bill collectors". Now SMS is unreliable, despite what many people assume, and I, for one, would like a record that I tried to send this message because if I don't = pay on time (let's say my message is lost) then I am fined - heavily! So I clearly feel that any SMS-like SIP service should provide the capability to store sent messages for later recall. Paul DS Paul D.Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.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-bounces@ietf.org Mon Jun 7 11:38:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24223 for ; Mon, 7 Jun 2004 11:38:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMCa-0002aq-8z for simple-archive@ietf.org; Mon, 07 Jun 2004 11:38:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMAx-0001kd-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 11:36:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXM9Z-0000m8-01; Mon, 07 Jun 2004 11:35:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXM37-0003f6-6B; Mon, 07 Jun 2004 11:28:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXLxM-0004S5-E3; Mon, 07 Jun 2004 11:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSfrE-0003sw-Cl for simple@megatron.ietf.org; Tue, 25 May 2004 13:36: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 NAA02452 for ; Tue, 25 May 2004 13:36:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSfrD-0002s7-88 for simple@ietf.org; Tue, 25 May 2004 13:36:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSfqF-0002pq-00 for simple@ietf.org; Tue, 25 May 2004 13:35:56 -0400 Received: from c24375.rim.net ([216.9.243.75] helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1BSfpc-0002lT-00 for simple@ietf.org; Tue, 25 May 2004 13:35:16 -0400 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 91F5AB9B7E for ; Tue, 25 May 2004 13:34:40 -0400 (EDT) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2004052513344010838 ; Tue, 25 May 2004 13:34:40 -0400 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 May 2004 13:34:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Re: MSRP: Max message size indication Date: Tue, 25 May 2004 13:34:39 -0400 Message-ID: Thread-Topic: [Simple] Re: MSRP: Max message size indication Thread-Index: AcRCaz4taaorO6PPSlqTitwTnRH7qwAE1BEJ From: "Andrew Allen" To: , X-OriginalArrivalTime: 25 May 2004 17:34:40.0316 (UTC) FILETIME=[8ED9AFC0:01C4427E] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Jun 2004 11:22:07 -0400 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This proposal makes a lot of sense for mobile devices which have limited = memory and for which the transmission bandwidth may be limited and the = cost of which may be significant. It makes little sense to transmit (at a charge) and overwhelm a UA with = data that it cannot handle.=20 With messaging we are dealing with the potential interoperability = between devices with significantly different memory and and = communication link capacities so this feature seems an important = requirement to include. Since the message sessions draft is at a stage where it is still easy to = make such a change it would seem now is the time to include this = enhancement which seems relatively straight forward. Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 European Mobile +358 50 467 5870 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld -----Original Message----- From: simple-bounces@ietf.org To: Christer Holmberg (JO/LMF) CC: 'simple@ietf.org' Sent: Tue May 25 10:48:52 2004 Subject: [Simple] Re: MSRP: Max message size indication (Oops, itchy trigger finger--ignore my last mail on the subject.) I do not have strong feelings on this as a requirement. If we do want to = do it, the general approach seems good at the first read, anyway. I=20 don't think there is a need for the non-type specific size attribute.=20 The only advantage would be to reduce size of the SDP. I don't see that=20 as a big requirement, since it normally only happens one per session. Do others have thoughts on the matter? Do we need this feature at all? Christer Holmberg (JO/LMF) wrote: > Hi, >=20 > As agreed at the SIMPLE interim meeting MSRP discussion I am bringing = to the list the issue about being able to indicate the max content size = a node is able to receive. Also, as input, in chapter 4 of = draft-rosenberg-simple-messaging-requirements-01.txt there is a = requirement for such functionality: >=20 > REQ-CONTENT-1: A UA MUST be able to indicate the maximum message size = it is willing to receive.=20 >=20 > I think it would be useful if clients could indicate the maximum = payload size he is able to receive, and also send, either per type or = stream. Note that I am talking about the total message/content size, not = the size of individual fragments (the spec does say that messages bigger = than 2k should be fragmented). >=20 > If the max size is dependent on the media type, max size could be = defined as a accept-type token paramter: >=20 > example: >=20 > accept-type: X;max-send=3D1000;max-receive=3D1000, = Y;max-send=3D2000;max-receive=3D500 >=20 > And, if the message size it not type dependent, generic max size = attributes could be used. >=20 > example: >=20 > a=3Dmax-send: 1000 > a=3Dmax-receive:1000 >=20 > Even if one is not going to send more than the other party indicates = he is able to receive I still think it is important that a node can = indicate how much he is able to send. For example, the remote node may = reserve memory according to that information, and/or intermediate = proxies may do forking/routing based on the client capabilities. >=20 > An MSRP "message size too big" error code could also be useful, if a = node for whatever reason is not able to accept a SEND message. This may = be due to that the remote node is sending more data than was agreed in = the offer/answer, but also due to that the receiving node for a short = period isn't able to receive the agreed data size (if the max size = change is permanent a new offer should of course be sent, instead of = sending an error reply to every SEND). At the interim meeting is was = desired to have a mechanism to "interrupt" the receival of a message, = and this error code could be used to indicate that. The sender would = then stop sending the message, and any possible yet unsent fragments. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland _______________________________________________ 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-bounces@ietf.org Mon Jun 7 11:44:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24702 for ; Mon, 7 Jun 2004 11:44:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMIV-0005mP-7Y for simple-archive@ietf.org; Mon, 07 Jun 2004 11:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMHc-0005JP-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 11:43:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXMGV-0004P5-00; Mon, 07 Jun 2004 11:42:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMDa-0008Sy-Mn; Mon, 07 Jun 2004 11:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXM6u-0006dW-D5 for simple@megatron.ietf.org; Mon, 07 Jun 2004 11:32: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 LAA23886 for ; Mon, 7 Jun 2004 11:32:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXM6t-0007d9-Iz for simple@ietf.org; Mon, 07 Jun 2004 11:32:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXM5x-0007AR-00 for simple@ietf.org; Mon, 07 Jun 2004 11:31:30 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXM5A-0006Mm-00 for simple@ietf.org; Mon, 07 Jun 2004 11:30:40 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i57FU7Lp020960; Mon, 7 Jun 2004 10:30:07 -0500 Message-ID: <40C489F9.1010706@dynamicsoft.com> Date: Mon, 07 Jun 2004 10:30:01 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton Subject: Re: [Simple] Re: MSRP: Max message size indication References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I'd like to try and get some closure on this: Please answer yes or no to the following: 1) Should we add the optional signaling of the maximum content size you are willing to _receive_ into the SDP exchange. 2) Should we add the optional signaling of the maximum content size you are planning to _send_ into the SDP exchange. 3) If either 1 or 2 is yes, do we send one value for the session, or one value per each type for which we have indicated support. My personal opinions: No and No. In all honesty, I think this could be a useful feature, but I don't think MSRP has to have it to function. I am voting no, not because I disagree with the feature, but because I don't want to add additional work to completing MSRP unless it is absolutely necessary. But if consensus says we need it, I do not object on any technical basis. Chris Boulton wrote: > I think this feature would certainly be useful for max receive (if it was type specific) BUT I am not convinced about send. > > Chris. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tue 25/05/2004 18:27 > To: Christer Holmberg (JO/LMF) > Cc: hisham.khartabil@nokia.com; simple@ietf.org > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > > Let me step up a level: > > By the required vs useful discussion, I was referring to the feature of > being able to signal size limitations itself, rather than some aspect of > the feature. > > So, what do others about whether the feature of being able to signal > message size limits is required? > > Christer Holmberg (JO/LMF) wrote: > > > Hi, > > > > > >>(Ignore my yet-another-empty reply. This time I blame the combined > >>ergonomics of Thunderbird and my laptop.) > >> > >>That brings up an interesting meta-question. What is the bar > >>for putting new features into MSRP at this stage? Is "useful" enough? Or > >>should we limit new features to things that we decide are "required." > > > > > > Well, the max-receive is required, and I think it is very useful. As I wrote earlier, the question is if it should be possible to indicate separate values for different media types. > > > > The max-send is not required, but I still think it would be very useful. Earlier I gave some examples I think are very valid (nodes may try to reserve memory according to how much big messages then can expect to receive, redirection/forking may be done based on the information etc etc etc). It wouldn't have any impacts on the protocol functionality itself, and there would be no interop problems with nodes that don't understand the max-send attribute/parameter (or just don't care about it). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > >>hisham.khartabil@nokia.com wrote: > >> > >> > >>>I think max-receive is useful, but not max-send. > >>> > >>>/Hisham > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: simple-bounces@ietf.org > >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>>>Of ext Ben Campbell > >>>>Sent: 25.May.2004 17:49 > >>>>To: Christer Holmberg (JO/LMF) > >>>>Cc: 'simple@ietf.org' > >>>>Subject: [Simple] Re: MSRP: Max message size indication > >>>> > >>>> > >>>>(Oops, itchy trigger finger--ignore my last mail on the subject.) > >>>> > >>>>I do not have strong feelings on this as a requirement. If we > >>>>do want to > >>>>do it, the general approach seems good at the first read, anyway. I > >>>>don't think there is a need for the non-type specific size > >> > >>attribute. > >> > >>>>The only advantage would be to reduce size of the SDP. I > >>>>don't see that > >>>>as a big requirement, since it normally only happens one > >> > >>per session. > >> > >>>>Do others have thoughts on the matter? Do we need this > >> > >>feature at all? > >> > >>>> > >>>> > >>>>Christer Holmberg (JO/LMF) wrote: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > >>>> > >>>>am bringing to the list the issue about being able to > >>>>indicate the max content size a node is able to receive. > >>>>Also, as input, in chapter 4 of > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >>>>a requirement for such functionality: > >>>> > >>>> > >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >>>> > >>>>message size it is willing to receive. > >>>> > >>>> > >>>>>I think it would be useful if clients could indicate the > >>>> > >>>>maximum payload size he is able to receive, and also send, > >>>>either per type or stream. Note that I am talking about the > >>>>total message/content size, not the size of individual > >>>>fragments (the spec does say that messages bigger than 2k > >>>>should be fragmented). > >>>> > >>>> > >>>>>If the max size is dependent on the media type, max size > >>>> > >>>>could be defined as a accept-type token paramter: > >>>> > >>>> > >>>>>example: > >>>>> > >>>>>accept-type: X;max-send=1000;max-receive=1000, > >>>> > >>>>Y;max-send=2000;max-receive=500 > >>>> > >>>> > >>>>>And, if the message size it not type dependent, generic max > >>>> > >>>>size attributes could be used. > >>>> > >>>> > >>>>>example: > >>>>> > >>>>>a=max-send: 1000 > >>>>>a=max-receive:1000 > >>>>> > >>>>>Even if one is not going to send more than the other party > >>>> > >>>>indicates he is able to receive I still think it is important > >>>>that a node can indicate how much he is able to send. For > >>>>example, the remote node may reserve memory according to that > >>>>information, and/or intermediate proxies may do > >>>>forking/routing based on the client capabilities. > >>>> > >>>> > >>>>>An MSRP "message size too big" error code could also be > >>>> > >>>>useful, if a node for whatever reason is not able to accept a > >>>>SEND message. This may be due to that the remote node is > >>>>sending more data than was agreed in the offer/answer, but > >>>>also due to that the receiving node for a short period isn't > >>>>able to receive the agreed data size (if the max size change > >>>>is permanent a new offer should of course be sent, instead of > >>>>sending an error reply to every SEND). At the interim meeting > >>>>is was desired to have a mechanism to "interrupt" the > >>>>receival of a message, and this error code could be used to > >>>>indicate that. The sender would then stop sending the > >>>>message, and any possible yet unsent fragments. > >>>> > >>>> > >>>>>Regards, > >>>>> > >>>>>Christer Holmberg > >>>>>Ericsson Finland > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 > > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.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-bounces@ietf.org Mon Jun 7 13:09:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29190 for ; Mon, 7 Jun 2004 13:09:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNcg-0007SO-VM for simple-archive@ietf.org; Mon, 07 Jun 2004 13:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNaS-0006J9-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 13:07:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXNXO-0005Ib-01; Mon, 07 Jun 2004 13:03:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXNHY-0002Oy-Pd; Mon, 07 Jun 2004 12:47:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNEw-00004r-63; Mon, 07 Jun 2004 12:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXN7q-00073s-FU for simple@megatron.ietf.org; Mon, 07 Jun 2004 12:37: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 MAA27449 for ; Mon, 7 Jun 2004 12:37:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXN7p-0000dW-AQ for simple@ietf.org; Mon, 07 Jun 2004 12:37:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXN6k-000075-00 for simple@ietf.org; Mon, 07 Jun 2004 12:36:23 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1BXN5i-0006uE-00 for simple@ietf.org; Mon, 07 Jun 2004 12:35:18 -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 i57GYgV4006487; Mon, 7 Jun 2004 11:34:43 -0500 (CDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jun 2004 11:34:42 -0500 Message-ID: From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Ben Campbell , christer.holmberg@ericsson.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Mon, 7 Jun 2004 11:34:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hisham Khartabil wrote: > Mandating chunking for messages larger than x bytes seems to > enable receivers to send back a 4xx response telling the > sender to stop. I'm not certain this is necessary, and I'm pretty sure that it's not sufficient. For starters, we haven't yet said that you must wait for the end of a message before you respond to it. I see no reason that you couldn't send an error response to a SEND transaction while it's still streaming at you. The adjacent hop could then stop sending you the content (that is, send the boundary with a "+" indicator at the end -- or possibly, we could add a new "!" indicator that means "aborted."). The issue of squelching the message all the way back to the sender (in the case of a session with relays) is also slightly problematic, unless we do something like mandate that negative DSNs are always on. I don't think that all parties involved in this discussion would be happy with such a decision. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 13:18:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29652 for ; Mon, 7 Jun 2004 13:18:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNlX-0004v0-3K for simple-archive@ietf.org; Mon, 07 Jun 2004 13:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNkc-0004OQ-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 13:17:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXNk7-0003rM-00; Mon, 07 Jun 2004 13:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNaa-0006Fu-8z; Mon, 07 Jun 2004 13:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNM8-0002EU-Tt for simple@megatron.ietf.org; Mon, 07 Jun 2004 12: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 MAA28503 for ; Mon, 7 Jun 2004 12:52:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNM7-0007Ep-W6 for simple@ietf.org; Mon, 07 Jun 2004 12:52:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNKV-0006Zq-00 for simple@ietf.org; Mon, 07 Jun 2004 12:50:36 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXNIn-0005up-00 for simple@ietf.org; Mon, 07 Jun 2004 12:48:49 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57GmnAh004128 for ; Mon, 7 Jun 2004 18:48:49 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 18:48:49 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 18:48:49 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" Date: Mon, 7 Jun 2004 18:48:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 07 Jun 2004 16:48:49.0163 (UTC) FILETIME=[4E67CDB0:01C44CAF] Subject: [Simple] MSRP: Ending a session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Chapter 6.5.4 in the MSRP draft (version -06) says: "When either endpoint in an MSRP session wishes to end the session, it first signals its intent using the normal processing for the signaling protocol. For example, in SIP, it would send a BYE request to the peer. After agreeing to end the session, the host endpoint MUST release any resources acquired as part of the session." Later in the chapter it is also described how possible outstanding MSRP transactions are handled when a session is to be released. Now, I don't think it should be a must for a node to wait for a node to receive the BYE response before the TCP resources are released. Many nodes releases the media resources at the same time as the BYE is sent. And, even if would keep the connection open for possible outstanding MSRP transactions they would most likely be "lost" anyway, since a user will not (in gateway scenarios may not even be able to) wait for possible messages after the release message is sent. Also, chapter 15.1.1 in RFC3261 says: "Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction." To me this clearly indicates that a node does not need to keep resources and wait for anything after the BYE is sent. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 13:21:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29836 for ; Mon, 7 Jun 2004 13:21:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNoj-0006a9-Td for simple-archive@ietf.org; Mon, 07 Jun 2004 13:21:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNnp-00061E-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 13:20:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXNn6-0005I2-00; Mon, 07 Jun 2004 13:20:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNan-0006Ib-74; Mon, 07 Jun 2004 13:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNRG-0003oa-2H for simple@megatron.ietf.org; Mon, 07 Jun 2004 12:57: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 MAA28746 for ; Mon, 7 Jun 2004 12:57:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNRE-0002NL-8f for simple@ietf.org; Mon, 07 Jun 2004 12:57:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNQH-0001sD-00 for simple@ietf.org; Mon, 07 Jun 2004 12:56:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BXNPm-0001MV-00 for simple@ietf.org; Mon, 07 Jun 2004 12:56:02 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 Jun 2004 12:59:19 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i57GtU2V003939; Mon, 7 Jun 2004 12:55:30 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-2-76.cisco.com [10.86.242.76]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJE87849; Mon, 7 Jun 2004 12:55:26 -0400 (EDT) Message-ID: <40C49DFE.1070804@cisco.com> Date: Mon, 07 Jun 2004 12:55:26 -0400 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 Subject: Re: [Simple] Re: MSRP: Max message size indication References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> <40C489F9.1010706@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, I'm inclined to agree with you (no/no). For many nodes this is simply not a number that is easily decided. If anything, I imagine it would be best to negotiate this. But that requires the sender to pick a maximum send value, even though the sender probably has no particular limit. This just seems like a rat hole best avoided for now. Paul Ben Campbell wrote: > I'd like to try and get some closure on this: > > Please answer yes or no to the following: > > 1) Should we add the optional signaling of the maximum content size you > are willing to _receive_ into the SDP exchange. > > 2) Should we add the optional signaling of the maximum content size you > are planning to _send_ into the SDP exchange. > > 3) If either 1 or 2 is yes, do we send one value for the session, or one > value per each type for which we have indicated support. > > My personal opinions: > > No and No. In all honesty, I think this could be a useful feature, but I > don't think MSRP has to have it to function. I am voting no, not because > I disagree with the feature, but because I don't want to add additional > work to completing MSRP unless it is absolutely necessary. But if > consensus says we need it, I do not object on any technical basis. > > > > > Chris Boulton wrote: > >> I think this feature would certainly be useful for max receive (if it >> was type specific) BUT I am not convinced about send. >> >> Chris. >> >> >> -----Original Message----- From: Ben Campbell >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue 25/05/2004 18:27 >> To: Christer Holmberg (JO/LMF) Cc: hisham.khartabil@nokia.com; >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max message size >> indication >> >> >> >> Let me step up a level: >> >> By the required vs useful discussion, I was referring to the >> feature of >> being able to signal size limitations itself, rather than some >> aspect of >> the feature. >> >> So, what do others about whether the feature of being able to signal >> message size limits is required? >> >> Christer Holmberg (JO/LMF) wrote: >> >> > Hi, >> > >> > >> >>(Ignore my yet-another-empty reply. This time I blame the combined >> >>ergonomics of Thunderbird and my laptop.) >> >> >> >>That brings up an interesting meta-question. What is the bar >> >>for putting new features into MSRP at this stage? Is "useful" >> enough? Or >> >>should we limit new features to things that we decide are >> "required." >> > >> > >> > Well, the max-receive is required, and I think it is very >> useful. As I wrote earlier, the question is if it should be possible >> to indicate separate values for different media types. >> > >> > The max-send is not required, but I still think it would be very >> useful. Earlier I gave some examples I think are very valid (nodes may >> try to reserve memory according to how much big messages then can >> expect to receive, redirection/forking may be done based on the >> information etc etc etc). It wouldn't have any impacts on the protocol >> functionality itself, and there would be no interop problems with >> nodes that don't understand the max-send attribute/parameter (or just >> don't care about it). >> > >> > Regards, >> > >> > Christer Holmberg >> > Ericsson Finland >> > >> > >> > >> >>hisham.khartabil@nokia.com wrote: >> >> >> >> >> >>>I think max-receive is useful, but not max-send. >> >>> >> >>>/Hisham >> >>> >> >>> >> >>> >> >>>>-----Original Message----- >> >>>>From: simple-bounces@ietf.org >> >>>>[mailto:simple-bounces@ietf.org]On Behalf >> >>>>Of ext Ben Campbell >> >>>>Sent: 25.May.2004 17:49 >> >>>>To: Christer Holmberg (JO/LMF) >> >>>>Cc: 'simple@ietf.org' >> >>>>Subject: [Simple] Re: MSRP: Max message size indication >> >>>> >> >>>> >> >>>>(Oops, itchy trigger finger--ignore my last mail on the subject.) >> >>>> >> >>>>I do not have strong feelings on this as a requirement. If we >> >>>>do want to >> >>>>do it, the general approach seems good at the first read, >> anyway. I >> >>>>don't think there is a need for the non-type specific size >> >> >> >>attribute. >> >> >> >>>>The only advantage would be to reduce size of the SDP. I >> >>>>don't see that >> >>>>as a big requirement, since it normally only happens one >> >> >> >>per session. >> >> >> >>>>Do others have thoughts on the matter? Do we need this >> >> >> >>feature at all? >> >> >> >>>> >> >>>> >> >>>>Christer Holmberg (JO/LMF) wrote: >> >>>> >> >>>> >> >>>> >> >>>>>Hi, >> >>>>> >> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I >> >>>> >> >>>>am bringing to the list the issue about being able to >> >>>>indicate the max content size a node is able to receive. >> >>>>Also, as input, in chapter 4 of >> >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is >> >>>>a requirement for such functionality: >> >>>> >> >>>> >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum >> >>>> >> >>>>message size it is willing to receive. >> >>>> >> >>>> >> >>>>>I think it would be useful if clients could indicate the >> >>>> >> >>>>maximum payload size he is able to receive, and also send, >> >>>>either per type or stream. Note that I am talking about the >> >>>>total message/content size, not the size of individual >> >>>>fragments (the spec does say that messages bigger than 2k >> >>>>should be fragmented). >> >>>> >> >>>> >> >>>>>If the max size is dependent on the media type, max size >> >>>> >> >>>>could be defined as a accept-type token paramter: >> >>>> >> >>>> >> >>>>>example: >> >>>>> >> >>>>>accept-type: X;max-send=1000;max-receive=1000, >> >>>> >> >>>>Y;max-send=2000;max-receive=500 >> >>>> >> >>>> >> >>>>>And, if the message size it not type dependent, generic max >> >>>> >> >>>>size attributes could be used. >> >>>> >> >>>> >> >>>>>example: >> >>>>> >> >>>>>a=max-send: 1000 >> >>>>>a=max-receive:1000 >> >>>>> >> >>>>>Even if one is not going to send more than the other party >> >>>> >> >>>>indicates he is able to receive I still think it is important >> >>>>that a node can indicate how much he is able to send. For >> >>>>example, the remote node may reserve memory according to that >> >>>>information, and/or intermediate proxies may do >> >>>>forking/routing based on the client capabilities. >> >>>> >> >>>> >> >>>>>An MSRP "message size too big" error code could also be >> >>>> >> >>>>useful, if a node for whatever reason is not able to accept a >> >>>>SEND message. This may be due to that the remote node is >> >>>>sending more data than was agreed in the offer/answer, but >> >>>>also due to that the receiving node for a short period isn't >> >>>>able to receive the agreed data size (if the max size change >> >>>>is permanent a new offer should of course be sent, instead of >> >>>>sending an error reply to every SEND). At the interim meeting >> >>>>is was desired to have a mechanism to "interrupt" the >> >>>>receival of a message, and this error code could be used to >> >>>>indicate that. The sender would then stop sending the >> >>>>message, and any possible yet unsent fragments. >> >>>> >> >>>> >> >>>>>Regards, >> >>>>> >> >>>>>Christer Holmberg >> >>>>>Ericsson Finland >> >>>> >> >>>> >> >>>>_______________________________________________ >> >>>>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 >> >> >> >> >> This message has been scanned for viruses by MailControl - >> www.mailcontrol.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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 13:28:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00365 for ; Mon, 7 Jun 2004 13:28:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNvG-0002qi-5L for simple-archive@ietf.org; Mon, 07 Jun 2004 13:28:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNuM-0002Jn-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 13:27:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXNts-0001lL-00; Mon, 07 Jun 2004 13:27:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNpq-0001y9-9s; Mon, 07 Jun 2004 13:22:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNbz-0006tE-1k for simple@megatron.ietf.org; Mon, 07 Jun 2004 13:08: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 NAA29048 for ; Mon, 7 Jun 2004 13:08:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNby-0007DQ-1X for simple@ietf.org; Mon, 07 Jun 2004 13:08:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNZi-000679-00 for simple@ietf.org; Mon, 07 Jun 2004 13:06:18 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BXNXB-0005IX-00 for simple@ietf.org; Mon, 07 Jun 2004 13:03:42 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57H3fPA021560 for ; Mon, 7 Jun 2004 19:03:41 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 19:03:41 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 19:03:41 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" Date: Mon, 7 Jun 2004 19:03:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 07 Jun 2004 17:03:41.0075 (UTC) FILETIME=[6206C630:01C44CB1] Subject: [Simple] MSRP: updated offer on transaction timeout or non-2xx/415 respons e X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I have a question about the case if a non-2xx/415 response is received, or a timeout occurs, for a MSRP message. Chapter 6.5.3 says: "8. If any other response code is received, or if the transaction times out, the endpoint SHOULD assume the session has failed, either tear down the session, or attempt to re-establish the session by sending an updated SDP offer proposing a new connection. If a new connection is established, the endpoint MAY choose to resend the content on the new connection." My question is: what information in the updated the MSRP media description (m= line) should be changed, to indicate that the connection should be re-established, ie that the the m= line is not unchanged, and only send eg as part of a refresh? The SDP session level o= parameter is not enough, because the SDP may contain multiple media descriptions (m= line), and one needs to find out which has been updated? Since the c= line IP address, and m= line port, has no meaning in MSRP I guess something in the path attribute would have to be updated, or? If one doesn't want to change the IP address/port (may not be possible eg due to firewalls), does a new resource value indicate that the TCP connection should be re-established? Also, does the node really need to send an updated SDP in the first place, if the IP parameters don't change? Why not just trying to re-establish the TCP connection? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 13:40:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00859 for ; Mon, 7 Jun 2004 13:40:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXO7B-0001nN-Uo for simple-archive@ietf.org; Mon, 07 Jun 2004 13:40:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXO6K-0001Dl-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 13:40:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXO5M-0000aF-00; Mon, 07 Jun 2004 13:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNsw-0002iy-F4; Mon, 07 Jun 2004 13:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNoT-0001d0-6p for simple@megatron.ietf.org; Mon, 07 Jun 2004 13:21:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29765 for ; Mon, 7 Jun 2004 13:21:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNoS-0006Y6-7j for simple@ietf.org; Mon, 07 Jun 2004 13:21:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNnU-0005te-00 for simple@ietf.org; Mon, 07 Jun 2004 13:20:33 -0400 Received: from mail.viack.com ([12.129.16.132]) by ietf-mx with esmtp (Exim 4.12) id 1BXNlU-0004Op-00 for simple@ietf.org; Mon, 07 Jun 2004 13:18:28 -0400 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Ending a session Date: Mon, 7 Jun 2004 10:17:56 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Ending a session Thread-Index: AcRMszu29L6CZsesTXe8ZwZOTL73WAAAAnvw From: "Lisa Guo" To: "Christer Holmberg (JO/LMF)" , , Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Could anybody tell me how to unsubscribe from this mailing list? Thanks, Lisa -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 07, 2004 9:49 AM To: 'simple@ietf.org'; 'bcampbell@dynamicsoft.com' Subject: [Simple] MSRP: Ending a session Hi, Chapter 6.5.4 in the MSRP draft (version -06) says: "When either endpoint in an MSRP session wishes to end the session, it first signals its intent using the normal processing for the signaling protocol. For example, in SIP, it would send a BYE request to the peer. After agreeing to end the session, the host endpoint MUST release any resources acquired as part of the session." Later in the chapter it is also described how possible outstanding MSRP = transactions are handled when a session is to be released. Now, I don't think it should be a must for a node to wait for a node to = receive the BYE response before the TCP resources are released. Many = nodes releases the media resources at the same time as the BYE is sent. = And, even if would keep the connection open for possible outstanding = MSRP transactions they would most likely be "lost" anyway, since a user = will not (in gateway scenarios may not even be able to) wait for = possible messages after the release message is sent. Also, chapter 15.1.1 in RFC3261 says: "Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction." To me this clearly indicates that a node does not need to keep resources = and wait for anything after the BYE is sent. Regards, Christer Holmberg Ericsson Finland _______________________________________________ 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-bounces@ietf.org Mon Jun 7 13:43:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01013 for ; Mon, 7 Jun 2004 13:43:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOA5-0003VK-RL for simple-archive@ietf.org; Mon, 07 Jun 2004 13:43:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXO91-0002wK-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 13:42:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXO8F-0002KP-00; Mon, 07 Jun 2004 13:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNzt-0004gT-Cd; Mon, 07 Jun 2004 13:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNrr-0002RZ-RJ for simple@megatron.ietf.org; Mon, 07 Jun 2004 13:25: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 NAA00247 for ; Mon, 7 Jun 2004 13:25:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXNrq-0000fZ-Os for simple@ietf.org; Mon, 07 Jun 2004 13:25:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXNqw-00004v-00 for simple@ietf.org; Mon, 07 Jun 2004 13:24:08 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXNpm-0007EJ-00 for simple@ietf.org; Mon, 07 Jun 2004 13:22:54 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57HMsAh006944 for ; Mon, 7 Jun 2004 19:22:54 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 19:22:54 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 19:22:54 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" , Ben Campbell Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Mon, 7 Jun 2004 19:22:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jun 2004 17:22:54.0064 (UTC) FILETIME=[1142EF00:01C44CB4] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I disagree, and my answer is yes/yes. >I'm inclined to agree with you (no/no). For many nodes this is simply=20 >not a number that is easily decided. If anything, I imagine=20 >it would be best to negotiate this. But that requires the sender to = pick=20 >a maximum send value, even though the sender probably has no = particular limit.=20 >This just seems like a rat hole best avoided for now. The support and use of the attribute/parameter would be OPTIONAL, so if = a node doesn't support the attribute/parameter (it is not able to = calculate a value, it can't be configured, or the node simply thinks = that size doesn't matter) everything will still work, as today, and it = will then be "local policy" what to do if the messages can't be = handled. Of course, a node can send a 4xx response if the message it receives is = too big, but as I said before, there may be scenarios where the size = information is used to make decissions already at the session setup = phase. As Andrew said, this feature is especially useful for mobile devices, = or other nodes with limited memory. And, since there is a requirement at least for the receiving part, I = assume it at some stage has been realized that the information could be = useful. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 7. kes=E4kuuta 2004 19:55 > To: Ben Campbell > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > simple@ietf.org; Christer > Holmberg (JO/LMF) > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Ben, >=20 >=20 > Paul >=20 > Ben Campbell wrote: > > I'd like to try and get some closure on this: > >=20 > > Please answer yes or no to the following: > >=20 > > 1) Should we add the optional signaling of the maximum=20 > content size you=20 > > are willing to _receive_ into the SDP exchange. > >=20 > > 2) Should we add the optional signaling of the maximum=20 > content size you=20 > > are planning to _send_ into the SDP exchange. > >=20 > > 3) If either 1 or 2 is yes, do we send one value for the=20 > session, or one=20 > > value per each type for which we have indicated support. > >=20 > > My personal opinions: > >=20 > > No and No. In all honesty, I think this could be a useful=20 > feature, but I=20 > > don't think MSRP has to have it to function. I am voting=20 > no, not because=20 > > I disagree with the feature, but because I don't want to=20 > add additional=20 > > work to completing MSRP unless it is absolutely necessary. But if=20 > > consensus says we need it, I do not object on any technical basis. > >=20 > >=20 > >=20 > >=20 > > Chris Boulton wrote: > >=20 > >> I think this feature would certainly be useful for max=20 > receive (if it=20 > >> was type specific) BUT I am not convinced about send. > >> =20 > >> Chris. > >> =20 > >> > >> -----Original Message----- From: Ben Campbell=20 > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue 25/05/2004 18:27=20 > >> To: Christer Holmberg (JO/LMF) Cc:=20 > hisham.khartabil@nokia.com;=20 > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > message size=20 > >> indication > >> =20 > >> =20 > >> > >> Let me step up a level: > >> =20 > >> By the required vs useful discussion, I was referring to the=20 > >> feature of > >> being able to signal size limitations itself, rather than some = > >> aspect of > >> the feature. > >> =20 > >> So, what do others about whether the feature of being=20 > able to signal > >> message size limits is required? > >> =20 > >> Christer Holmberg (JO/LMF) wrote: > >> =20 > >> > Hi, > >> > > >> > > >> >>(Ignore my yet-another-empty reply. This time I=20 > blame the combined > >> >>ergonomics of Thunderbird and my laptop.) > >> >> > >> >>That brings up an interesting meta-question. What is the bar > >> >>for putting new features into MSRP at this stage? Is=20 > "useful"=20 > >> enough? Or > >> >>should we limit new features to things that we decide are=20 > >> "required." > >> > > >> > > >> > Well, the max-receive is required, and I think it is very=20 > >> useful. As I wrote earlier, the question is if it should=20 > be possible=20 > >> to indicate separate values for different media types. > >> > > >> > The max-send is not required, but I still think it=20 > would be very=20 > >> useful. Earlier I gave some examples I think are very=20 > valid (nodes may=20 > >> try to reserve memory according to how much big messages then can=20 > >> expect to receive, redirection/forking may be done based on the=20 > >> information etc etc etc). It wouldn't have any impacts on=20 > the protocol=20 > >> functionality itself, and there would be no interop problems with=20 > >> nodes that don't understand the max-send=20 > attribute/parameter (or just=20 > >> don't care about it). > >> > > >> > Regards, > >> > > >> > Christer Holmberg > >> > Ericsson Finland > >> > > >> > > >> > > >> >>hisham.khartabil@nokia.com wrote: > >> >> > >> >> > >> >>>I think max-receive is useful, but not max-send. > >> >>> > >> >>>/Hisham > >> >>> > >> >>> > >> >>> > >> >>>>-----Original Message----- > >> >>>>From: simple-bounces@ietf.org > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >> >>>>Of ext Ben Campbell > >> >>>>Sent: 25.May.2004 17:49 > >> >>>>To: Christer Holmberg (JO/LMF) > >> >>>>Cc: 'simple@ietf.org' > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >> >>>> > >> >>>> > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > on the subject.) > >> >>>> > >> >>>>I do not have strong feelings on this as a=20 > requirement. If we > >> >>>>do want to > >> >>>>do it, the general approach seems good at the first read,=20 > >> anyway. I > >> >>>>don't think there is a need for the non-type specific size > >> >> > >> >>attribute. > >> >> > >> >>>>The only advantage would be to reduce size of the SDP. I > >> >>>>don't see that > >> >>>>as a big requirement, since it normally only happens one > >> >> > >> >>per session. > >> >> > >> >>>>Do others have thoughts on the matter? Do we need this > >> >> > >> >>feature at all? > >> >> > >> >>>> > >> >>>> > >> >>>>Christer Holmberg (JO/LMF) wrote: > >> >>>> > >> >>>> > >> >>>> > >> >>>>>Hi, > >> >>>>> > >> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > >> >>>> > >> >>>>am bringing to the list the issue about being able to > >> >>>>indicate the max content size a node is able to receive. > >> >>>>Also, as input, in chapter 4 of > >> =20 > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >> >>>>a requirement for such functionality: > >> >>>> > >> >>>> > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >> >>>> > >> >>>>message size it is willing to receive. > >> >>>> > >> >>>> > >> >>>>>I think it would be useful if clients could indicate the > >> >>>> > >> >>>>maximum payload size he is able to receive, and also send, > >> >>>>either per type or stream. Note that I am talking about = the > >> >>>>total message/content size, not the size of individual > >> >>>>fragments (the spec does say that messages bigger than 2k > >> >>>>should be fragmented). > >> >>>> > >> >>>> > >> >>>>>If the max size is dependent on the media type, max size > >> >>>> > >> >>>>could be defined as a accept-type token paramter: > >> >>>> > >> >>>> > >> >>>>>example: > >> >>>>> > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >> >>>> > >> >>>>Y;max-send=3D2000;max-receive=3D500 > >> >>>> > >> >>>> > >> >>>>>And, if the message size it not type dependent,=20 > generic max > >> >>>> > >> >>>>size attributes could be used. > >> >>>> > >> >>>> > >> >>>>>example: > >> >>>>> > >> >>>>>a=3Dmax-send: 1000 > >> >>>>>a=3Dmax-receive:1000 > >> >>>>> > >> >>>>>Even if one is not going to send more than the other = party > >> >>>> > >> >>>>indicates he is able to receive I still think it=20 > is important > >> >>>>that a node can indicate how much he is able to send. For > >> >>>>example, the remote node may reserve memory=20 > according to that > >> >>>>information, and/or intermediate proxies may do > >> >>>>forking/routing based on the client capabilities. > >> >>>> > >> >>>> > >> >>>>>An MSRP "message size too big" error code could also be > >> >>>> > >> >>>>useful, if a node for whatever reason is not able=20 > to accept a > >> >>>>SEND message. This may be due to that the remote node is > >> >>>>sending more data than was agreed in the offer/answer, but > >> >>>>also due to that the receiving node for a short=20 > period isn't > >> >>>>able to receive the agreed data size (if the max=20 > size change > >> >>>>is permanent a new offer should of course be sent,=20 > instead of > >> >>>>sending an error reply to every SEND). At the=20 > interim meeting > >> >>>>is was desired to have a mechanism to "interrupt" the > >> >>>>receival of a message, and this error code could be used = to > >> >>>>indicate that. The sender would then stop sending the > >> >>>>message, and any possible yet unsent fragments. > >> >>>> > >> >>>> > >> >>>>>Regards, > >> >>>>> > >> >>>>>Christer Holmberg > >> >>>>>Ericsson Finland > >> >>>> > >> >>>> > >> >>>>_______________________________________________ > >> >>>>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 > >> > >> > >> > >> This message has been scanned for viruses by MailControl -=20 > >> www.mailcontrol.com > >> > >> > >> > >>=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 14:17:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03389 for ; Mon, 7 Jun 2004 14:17:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOgs-0005EA-Fr for simple-archive@ietf.org; Mon, 07 Jun 2004 14:17:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOft-0004ev-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 14:16:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXOep-0003WS-00; Mon, 07 Jun 2004 14:15:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOVH-0003wk-Jt; Mon, 07 Jun 2004 14:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOMr-000271-Hs for simple@megatron.ietf.org; Mon, 07 Jun 2004 13: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 NAA01966 for ; Mon, 7 Jun 2004 13:57:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOMq-0002PX-Jh for simple@ietf.org; Mon, 07 Jun 2004 13:57:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOLd-0001kh-00 for simple@ietf.org; Mon, 07 Jun 2004 13:55:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BXOK4-0000lf-00 for simple@ietf.org; Mon, 07 Jun 2004 13:54:12 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Jun 2004 13:57:28 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i57Hrdpp021255; Mon, 7 Jun 2004 13:53:39 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-2-76.cisco.com [10.86.242.76]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJE94395; Mon, 7 Jun 2004 13:53:38 -0400 (EDT) Message-ID: <40C4ABA2.7020605@cisco.com> Date: Mon, 07 Jun 2004 13:53:38 -0400 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: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] MSRP: Ending a session References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Christer, Obviously you can't force anybody to do anything. If they want to cut you off in mid conversation then that is what they will do, just like hanging up on you in a conversation. But its not polite. In some sense the situation is no different with MSRP than it is with voice and RTP. However I think MSRP exposes issues that are small enough to ignore with voice. In particular, with voice, if you lose a small number of packets typically nobody cares, because with voice there is little information content in a small number of packets. But with MSRP, a "packet" (message) can have substantial content, so that whether it gets thru or not can have considerable significance. This will be true in all sorts of call flows, such as transfers, and is true here at the end of a session. So we should be defining mechanisms that can work gracefully, without loss of messages. Whether people use them that way is up to them. Also, I see many people talk as if BYE was the only way to end an MSRP session. But it is not. It may be ended simply by sending a reINVITE (or UPDATE) that drops the MSRP stream (by setting the port number to zero). This may not be a very useful thing to do when MSRP is the only medium in use, but it can make a lot of sense when there are other media. For instance, I might start in an IM session, then decide to add voice. Once voice has been added, I may just close my IM window, killing the MSRP stream. In a case like that there is more lattitude to keep the state of the stream until all the signaling to kill it is complete. For instance, when I close my IM window that can implicitly initiate the reinvite to drop the stream. But even though the window disappears, its state can remain. If another incoming message is received, the window can be popped again to show it to me. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > Chapter 6.5.4 in the MSRP draft (version -06) says: > > "When either endpoint in an MSRP session wishes to end the session, it > first signals its intent using the normal processing for the > signaling protocol. For example, in SIP, it would send a BYE request > to the peer. After agreeing to end the session, the host endpoint > MUST release any resources acquired as part of the session." > > Later in the chapter it is also described how possible outstanding MSRP transactions > are handled when a session is to be released. > > Now, I don't think it should be a must for a node to wait for a node to receive the BYE response before the TCP resources are released. Many nodes releases the media resources at the same time as the BYE is sent. And, even if would keep the connection open for possible outstanding MSRP transactions they would most likely be "lost" anyway, since a user will not (in gateway scenarios may not even be able to) wait for possible messages after the release message is sent. > > Also, chapter 15.1.1 in RFC3261 says: > > "Once the BYE is constructed, the UAC core creates a new non-INVITE > client transaction, and passes it the BYE request. The UAC MUST > consider the session terminated (and therefore stop sending or > listening for media) as soon as the BYE request is passed to the > client transaction." > > To me this clearly indicates that a node does not need to keep resources and wait for anything after the BYE is sent. > > Regards, > > Christer Holmberg > Ericsson Finland > > > _______________________________________________ > 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-bounces@ietf.org Mon Jun 7 14:21:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03568 for ; Mon, 7 Jun 2004 14:21:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOkd-0007K3-9o for simple-archive@ietf.org; Mon, 07 Jun 2004 14:21:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOjh-0006nw-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 14:20:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXOjD-0006HV-00; Mon, 07 Jun 2004 14:20:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOWA-0004G7-1t; Mon, 07 Jun 2004 14:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOSJ-0002uQ-NN for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:02: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 OAA02319 for ; Mon, 7 Jun 2004 14:02:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOSI-0005pB-Ll for simple@ietf.org; Mon, 07 Jun 2004 14:02:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXORV-0005Gj-00 for simple@ietf.org; Mon, 07 Jun 2004 14:01:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BXOQa-0004cm-00 for simple@ietf.org; Mon, 07 Jun 2004 14:00:56 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Jun 2004 14:01:00 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i57H0O2V021570; Mon, 7 Jun 2004 13:00:25 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-2-76.cisco.com [10.86.242.76]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJE95151; Mon, 7 Jun 2004 14:00:22 -0400 (EDT) Message-ID: <40C4AD36.7070507@cisco.com> Date: Mon, 07 Jun 2004 14:00:22 -0400 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: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] MSRP: updated offer on transaction timeout or non-2xx/415 respons e References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: > Hi, > > I have a question about the case if a non-2xx/415 response is received, or a timeout occurs, for a MSRP message. > > Chapter 6.5.3 says: > > "8. If any other response code is received, or if the transaction > times out, the endpoint SHOULD assume the session has failed, > either tear down the session, or attempt to re-establish the > session by sending an updated SDP offer proposing a new > connection. If a new connection is established, the endpoint MAY > choose to resend the content on the new connection." > > My question is: what information in the updated the MSRP media description (m= line) should be changed, to indicate that the connection should be re-established, ie that the the m= line is not unchanged, and only send eg as part of a refresh? The SDP session level o= parameter is not enough, because the SDP may contain multiple media descriptions (m= line), and one needs to find out which has been updated? Since the c= line IP address, and m= line port, has no meaning in MSRP I guess something in the path attribute would have to be updated, or? If one doesn't want to change the IP address/port (may not be possible eg due to firewalls), does a new resource value indicate that the TCP connection should be re-established? Assuming you don't have reason to change something else, it would be sufficient to simply change the 'resource' portion of the msrp url. > Also, does the node really need to send an updated SDP in the first place, if the IP parameters don't change? Why not just trying to re-establish the TCP connection? 1) because permitting this would require that a tcp listener always be active just in case this should happen. This could be a burden for some nodes. 2) because an attempt to establish a connection when one is already active is interpretted as an attack. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 14:24:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03730 for ; Mon, 7 Jun 2004 14:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOn0-0000fT-GW for simple-archive@ietf.org; Mon, 07 Jun 2004 14:24:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOlz-000075-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 14:23:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXOl6-0007K5-00; Mon, 07 Jun 2004 14:22:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOWD-0004Gr-1O; Mon, 07 Jun 2004 14:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOUF-0003QR-Rh for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:04: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 OAA02535 for ; Mon, 7 Jun 2004 14:04:42 -0400 (EDT) From: Corby.Wilson@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOUE-0006y9-KT for simple@ietf.org; Mon, 07 Jun 2004 14:04:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOTN-0006PA-00 for simple@ietf.org; Mon, 07 Jun 2004 14:03:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BXOSV-0005qY-00 for simple@ietf.org; Mon, 07 Jun 2004 14:02:55 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i57I1sx11557; Mon, 7 Jun 2004 21:01:54 +0300 (EET DST) X-Scanned: Mon, 7 Jun 2004 21:01:43 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i57I1hK4018269; Mon, 7 Jun 2004 21:01:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00HMFYNw; Mon, 07 Jun 2004 21:00:23 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i57I00H09181; Mon, 7 Jun 2004 21:00:00 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 7 Jun 2004 12:57:47 -0500 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] Re: MSRP: Max message size indication Date: Mon, 7 Jun 2004 12:57:47 -0500 Message-ID: <78E9902B779FD5428DB035B5F6A50EFB01A75CC8@daebe004.americas.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication Thread-Index: AcRMtvyUOZYmLZgMR9eCLrOViN8EogAAQTUg To: , , X-OriginalArrivalTime: 07 Jun 2004 17:57:47.0353 (UTC) FILETIME=[F0F57C90:01C44CB8] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I would say yes/yes as well, but it would be at session initiation. = Since the limit selected would be platform dependent it does not make = sense to send the max on every message. The supporting point here is that allowing small terminals to speed = things up a bit by letting the terminal transmit capabilities to the = peer to make things easier is a definite plus. I agree with Christer that this should be an OPTION only. Corby Wilson Nokia -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of ext Christer Holmberg (JO/LMF) Sent: Monday, June 07, 2004 1:23 PM To: 'Paul Kyzivat'; Ben Campbell Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Chris Boulton; = simple@ietf.org Subject: RE: [Simple] Re: MSRP: Max message size indication Hi, I disagree, and my answer is yes/yes. >I'm inclined to agree with you (no/no). For many nodes this is simply=20 >not a number that is easily decided. If anything, I imagine=20 >it would be best to negotiate this. But that requires the sender to = pick=20 >a maximum send value, even though the sender probably has no particular = limit.=20 >This just seems like a rat hole best avoided for now. The support and use of the attribute/parameter would be OPTIONAL, so if = a node doesn't support the attribute/parameter (it is not able to = calculate a value, it can't be configured, or the node simply thinks = that size doesn't matter) everything will still work, as today, and it = will then be "local policy" what to do if the messages can't be handled. Of course, a node can send a 4xx response if the message it receives is = too big, but as I said before, there may be scenarios where the size = information is used to make decissions already at the session setup = phase. As Andrew said, this feature is especially useful for mobile devices, or = other nodes with limited memory. And, since there is a requirement at least for the receiving part, I = assume it at some stage has been realized that the information could be = useful. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 7. kes=E4kuuta 2004 19:55 > To: Ben Campbell > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > simple@ietf.org; Christer > Holmberg (JO/LMF) > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Ben, >=20 >=20 > Paul >=20 > Ben Campbell wrote: > > I'd like to try and get some closure on this: > >=20 > > Please answer yes or no to the following: > >=20 > > 1) Should we add the optional signaling of the maximum=20 > content size you=20 > > are willing to _receive_ into the SDP exchange. > >=20 > > 2) Should we add the optional signaling of the maximum=20 > content size you=20 > > are planning to _send_ into the SDP exchange. > >=20 > > 3) If either 1 or 2 is yes, do we send one value for the=20 > session, or one=20 > > value per each type for which we have indicated support. > >=20 > > My personal opinions: > >=20 > > No and No. In all honesty, I think this could be a useful=20 > feature, but I=20 > > don't think MSRP has to have it to function. I am voting=20 > no, not because=20 > > I disagree with the feature, but because I don't want to=20 > add additional=20 > > work to completing MSRP unless it is absolutely necessary. But if=20 > > consensus says we need it, I do not object on any technical basis. > >=20 > >=20 > >=20 > >=20 > > Chris Boulton wrote: > >=20 > >> I think this feature would certainly be useful for max=20 > receive (if it=20 > >> was type specific) BUT I am not convinced about send. > >> =20 > >> Chris. > >> =20 > >> > >> -----Original Message----- From: Ben Campbell=20 > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue 25/05/2004 18:27=20 > >> To: Christer Holmberg (JO/LMF) Cc:=20 > hisham.khartabil@nokia.com;=20 > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > message size=20 > >> indication > >> =20 > >> =20 > >> > >> Let me step up a level: > >> =20 > >> By the required vs useful discussion, I was referring to the=20 > >> feature of > >> being able to signal size limitations itself, rather than some=20 > >> aspect of > >> the feature. > >> =20 > >> So, what do others about whether the feature of being=20 > able to signal > >> message size limits is required? > >> =20 > >> Christer Holmberg (JO/LMF) wrote: > >> =20 > >> > Hi, > >> > > >> > > >> >>(Ignore my yet-another-empty reply. This time I=20 > blame the combined > >> >>ergonomics of Thunderbird and my laptop.) > >> >> > >> >>That brings up an interesting meta-question. What is the bar > >> >>for putting new features into MSRP at this stage? Is=20 > "useful"=20 > >> enough? Or > >> >>should we limit new features to things that we decide are=20 > >> "required." > >> > > >> > > >> > Well, the max-receive is required, and I think it is very=20 > >> useful. As I wrote earlier, the question is if it should=20 > be possible=20 > >> to indicate separate values for different media types. > >> > > >> > The max-send is not required, but I still think it=20 > would be very=20 > >> useful. Earlier I gave some examples I think are very=20 > valid (nodes may=20 > >> try to reserve memory according to how much big messages then can=20 > >> expect to receive, redirection/forking may be done based on the=20 > >> information etc etc etc). It wouldn't have any impacts on=20 > the protocol=20 > >> functionality itself, and there would be no interop problems with=20 > >> nodes that don't understand the max-send=20 > attribute/parameter (or just=20 > >> don't care about it). > >> > > >> > Regards, > >> > > >> > Christer Holmberg > >> > Ericsson Finland > >> > > >> > > >> > > >> >>hisham.khartabil@nokia.com wrote: > >> >> > >> >> > >> >>>I think max-receive is useful, but not max-send. > >> >>> > >> >>>/Hisham > >> >>> > >> >>> > >> >>> > >> >>>>-----Original Message----- > >> >>>>From: simple-bounces@ietf.org > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >> >>>>Of ext Ben Campbell > >> >>>>Sent: 25.May.2004 17:49 > >> >>>>To: Christer Holmberg (JO/LMF) > >> >>>>Cc: 'simple@ietf.org' > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >> >>>> > >> >>>> > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > on the subject.) > >> >>>> > >> >>>>I do not have strong feelings on this as a=20 > requirement. If we > >> >>>>do want to > >> >>>>do it, the general approach seems good at the first read,=20 > >> anyway. I > >> >>>>don't think there is a need for the non-type specific size > >> >> > >> >>attribute. > >> >> > >> >>>>The only advantage would be to reduce size of the SDP. I > >> >>>>don't see that > >> >>>>as a big requirement, since it normally only happens one > >> >> > >> >>per session. > >> >> > >> >>>>Do others have thoughts on the matter? Do we need this > >> >> > >> >>feature at all? > >> >> > >> >>>> > >> >>>> > >> >>>>Christer Holmberg (JO/LMF) wrote: > >> >>>> > >> >>>> > >> >>>> > >> >>>>>Hi, > >> >>>>> > >> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > >> >>>> > >> >>>>am bringing to the list the issue about being able to > >> >>>>indicate the max content size a node is able to receive. > >> >>>>Also, as input, in chapter 4 of > >> =20 > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >> >>>>a requirement for such functionality: > >> >>>> > >> >>>> > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >> >>>> > >> >>>>message size it is willing to receive. > >> >>>> > >> >>>> > >> >>>>>I think it would be useful if clients could indicate the > >> >>>> > >> >>>>maximum payload size he is able to receive, and also send, > >> >>>>either per type or stream. Note that I am talking about the > >> >>>>total message/content size, not the size of individual > >> >>>>fragments (the spec does say that messages bigger than 2k > >> >>>>should be fragmented). > >> >>>> > >> >>>> > >> >>>>>If the max size is dependent on the media type, max size > >> >>>> > >> >>>>could be defined as a accept-type token paramter: > >> >>>> > >> >>>> > >> >>>>>example: > >> >>>>> > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >> >>>> > >> >>>>Y;max-send=3D2000;max-receive=3D500 > >> >>>> > >> >>>> > >> >>>>>And, if the message size it not type dependent,=20 > generic max > >> >>>> > >> >>>>size attributes could be used. > >> >>>> > >> >>>> > >> >>>>>example: > >> >>>>> > >> >>>>>a=3Dmax-send: 1000 > >> >>>>>a=3Dmax-receive:1000 > >> >>>>> > >> >>>>>Even if one is not going to send more than the other party > >> >>>> > >> >>>>indicates he is able to receive I still think it=20 > is important > >> >>>>that a node can indicate how much he is able to send. For > >> >>>>example, the remote node may reserve memory=20 > according to that > >> >>>>information, and/or intermediate proxies may do > >> >>>>forking/routing based on the client capabilities. > >> >>>> > >> >>>> > >> >>>>>An MSRP "message size too big" error code could also be > >> >>>> > >> >>>>useful, if a node for whatever reason is not able=20 > to accept a > >> >>>>SEND message. This may be due to that the remote node is > >> >>>>sending more data than was agreed in the offer/answer, but > >> >>>>also due to that the receiving node for a short=20 > period isn't > >> >>>>able to receive the agreed data size (if the max=20 > size change > >> >>>>is permanent a new offer should of course be sent,=20 > instead of > >> >>>>sending an error reply to every SEND). At the=20 > interim meeting > >> >>>>is was desired to have a mechanism to "interrupt" the > >> >>>>receival of a message, and this error code could be used to > >> >>>>indicate that. The sender would then stop sending the > >> >>>>message, and any possible yet unsent fragments. > >> >>>> > >> >>>> > >> >>>>>Regards, > >> >>>>> > >> >>>>>Christer Holmberg > >> >>>>>Ericsson Finland > >> >>>> > >> >>>> > >> >>>>_______________________________________________ > >> >>>>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 > >> > >> > >> > >> This message has been scanned for viruses by MailControl -=20 > >> www.mailcontrol.com > >> > >> > >> > >>=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 _______________________________________________ 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-bounces@ietf.org Mon Jun 7 14:31:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04216 for ; Mon, 7 Jun 2004 14:31:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOuC-0004pf-Qr for simple-archive@ietf.org; Mon, 07 Jun 2004 14:31:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOtK-0004Ir-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 14:30:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXOrX-0002v9-00; Mon, 07 Jun 2004 14:28:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOlh-0008Dj-7y; Mon, 07 Jun 2004 14:22:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOeR-0006Av-H6 for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:15: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 OAA03124 for ; Mon, 7 Jun 2004 14:15:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOeQ-0003XA-Et for simple@ietf.org; Mon, 07 Jun 2004 14:15:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOdA-0002tz-00 for simple@ietf.org; Mon, 07 Jun 2004 14:13:56 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BXOYt-0001qU-00 for simple@ietf.org; Mon, 07 Jun 2004 14:09:31 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57I9UWR015163 for ; Mon, 7 Jun 2004 20:09:30 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 20:09:30 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 20:09:30 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" Subject: RE: [Simple] MSRP: updated offer on transaction timeout or non-2x x/415 respons e Date: Mon, 7 Jun 2004 20:09:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 07 Jun 2004 18:09:30.0905 (UTC) FILETIME=[944F0090:01C44CBA] Cc: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Paul, Comments inline ([CHH]) >>I have a question about the case if a non-2xx/415 response >>is received, or a timeout occurs, for a MSRP message. >> >>Chapter 6.5.3 says: >> >>"8. If any other response code is received, or if the transaction >>times out, the endpoint SHOULD assume the session has failed, >>either tear down the session, or attempt to re-establish the >>session by sending an updated SDP offer proposing a new >>connection. If a new connection is established, the endpoint MAY >>choose to resend the content on the new connection." >> >>My question is: what information in the updated the MSRP >>media description (m= line) should be changed, to indicate >>that the connection should be re-established, ie that the the >>m= line is not unchanged, and only send eg as part of a >>refresh? The SDP session level o= parameter is not enough, >>because the SDP may contain multiple media descriptions (m= >>line), and one needs to find out which has been updated? >>Since the c= line IP address, and m= line port, has no >>meaning in MSRP I guess something in the path attribute would >>have to be updated, or? If one doesn't want to change the IP >>address/port (may not be possible eg due to firewalls), does >>a new resource value indicate that the TCP connection should >>be re-established? >Assuming you don't have reason to change something else, it would be >sufficient to simply change the 'resource' portion of the msrp url. [CHH] I guess it would be good to clarify that in the draft. Of course, there is also the case where there is no resource portion used (since it's optional), so I guess in that case it would have to be mandatory to include the resource portion in the updated offer. >Also, does the node really need to send an updated SDP in >the first place, if the IP parameters don't change? Why not >just trying to re-establish the TCP connection? > >1) because permitting this would require that a tcp listener >always be active just in case this should happen. This could be a >burden for some nodes. [CHH] That's a good point. However, doesn't a SIP node have to have the listener active always anyway, for incoming SIP requests (if TCP is used), since there is no requirement (it may be recommended, though) to keep a connection open for the whole session? >2) because an attempt to establish a connection when one is already >active is interpretted as an attack. [CHH] The offerer would tear down the old connection before establishing the new one, in the same way it would do when receiving an answer to an updated offer. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 14:35:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04498 for ; Mon, 7 Jun 2004 14:35:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOyB-0006zF-Ks for simple-archive@ietf.org; Mon, 07 Jun 2004 14:35:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOxM-0006TO-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 14:34:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXOwW-0005rR-00; Mon, 07 Jun 2004 14:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOlq-0008Il-He; Mon, 07 Jun 2004 14:22:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOfY-0006O8-O1 for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:16: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 OAA03256 for ; Mon, 7 Jun 2004 14:16:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOfX-0004FK-Lk for simple@ietf.org; Mon, 07 Jun 2004 14:16:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOeH-0003Vk-00 for simple@ietf.org; Mon, 07 Jun 2004 14:15:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BXOd2-0002i8-00 for simple@ietf.org; Mon, 07 Jun 2004 14:13:48 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i57I82ls029178; Mon, 7 Jun 2004 11:08:03 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-76.cisco.com [10.86.242.76]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJE96136; Mon, 7 Jun 2004 14:08:00 -0400 (EDT) Message-ID: <40C4AF00.40800@cisco.com> Date: Mon, 07 Jun 2004 14:08:00 -0400 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: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] Re: MSRP: Max message size indication References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA03256 Cc: hisham.khartabil@nokia.com, Chris Boulton , Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable You say this is all optional. But then you say that some nodes will make=20 use of sender maximum size to allocate resources on the receiving node.=20 So what happens when the sender doesn't specify? 1) sender specifies nothing, receiver assumes worst case. (The most it could possibly receive.) How is this better than doing nothing? 2) sender specifies nothing, receiver picks something less than worst case. Then there are things the sender won't be able to send that could have been sent had the sender requested so in advance. Not nice. I'm not opposed to investigating it further. But I do agree with Ben=20 that it is likely to slow things down. And if you intend for it to be=20 optional then it should be no problem to add later. Paul Christer Holmberg (JO/LMF) wrote: > Hi, >=20 > I disagree, and my answer is yes/yes. >=20 >=20 >>I'm inclined to agree with you (no/no). For many nodes this is simply=20 >>not a number that is easily decided. If anything, I imagine=20 >>it would be best to negotiate this. But that requires the sender to pi= ck=20 >>a maximum send value, even though the sender probably has no particular= limit.=20 >>This just seems like a rat hole best avoided for now. >=20 >=20 > The support and use of the attribute/parameter would be OPTIONAL, so if= a node doesn't support the attribute/parameter (it is not able to calcul= ate a value, it can't be configured, or the node simply thinks that size = doesn't matter) everything will still work, as today, and it will then be= "local policy" what to do if the messages can't be handled. >=20 > Of course, a node can send a 4xx response if the message it receives is= too big, but as I said before, there may be scenarios where the size inf= ormation is used to make decissions already at the session setup phase. >=20 > As Andrew said, this feature is especially useful for mobile devices, o= r other nodes with limited memory. >=20 > And, since there is a requirement at least for the receiving part, I as= sume it at some stage has been realized that the information could be use= ful. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 7. kes=E4kuuta 2004 19:55 >>To: Ben Campbell >>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 >>simple@ietf.org; Christer >>Holmberg (JO/LMF) >>Subject: Re: [Simple] Re: MSRP: Max message size indication >> >> >>Ben, >> >> >> Paul >> >>Ben Campbell wrote: >> >>>I'd like to try and get some closure on this: >>> >>>Please answer yes or no to the following: >>> >>>1) Should we add the optional signaling of the maximum=20 >> >>content size you=20 >> >>>are willing to _receive_ into the SDP exchange. >>> >>>2) Should we add the optional signaling of the maximum=20 >> >>content size you=20 >> >>>are planning to _send_ into the SDP exchange. >>> >>>3) If either 1 or 2 is yes, do we send one value for the=20 >> >>session, or one=20 >> >>>value per each type for which we have indicated support. >>> >>>My personal opinions: >>> >>>No and No. In all honesty, I think this could be a useful=20 >> >>feature, but I=20 >> >>>don't think MSRP has to have it to function. I am voting=20 >> >>no, not because=20 >> >>>I disagree with the feature, but because I don't want to=20 >> >>add additional=20 >> >>>work to completing MSRP unless it is absolutely necessary. But if=20 >>>consensus says we need it, I do not object on any technical basis. >>> >>> >>> >>> >>>Chris Boulton wrote: >>> >>> >>>>I think this feature would certainly be useful for max=20 >>> >>receive (if it=20 >> >>>>was type specific) BUT I am not convinced about send. >>>>=20 >>>>Chris. >>>>=20 >>>> >>>> -----Original Message----- From: Ben Campbell=20 >>>>[mailto:bcampbell@dynamicsoft.com] Sent: Tue 25/05/2004 18:27=20 >>>> To: Christer Holmberg (JO/LMF) Cc:=20 >>> >>hisham.khartabil@nokia.com;=20 >> >>>>simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 >>> >>message size=20 >> >>>>indication >>>> =20 >>>> =20 >>>> >>>> Let me step up a level: >>>> =20 >>>> By the required vs useful discussion, I was referring to the=20 >>>>feature of >>>> being able to signal size limitations itself, rather than some=20 >>>>aspect of >>>> the feature. >>>> =20 >>>> So, what do others about whether the feature of being=20 >>> >>able to signal >> >>>> message size limits is required? >>>> =20 >>>> Christer Holmberg (JO/LMF) wrote: >>>> =20 >>>> > Hi, >>>> > >>>> > >>>> >>(Ignore my yet-another-empty reply. This time I=20 >>> >>blame the combined >> >>>> >>ergonomics of Thunderbird and my laptop.) >>>> >> >>>> >>That brings up an interesting meta-question. What is the bar >>>> >>for putting new features into MSRP at this stage? Is=20 >>> >>"useful"=20 >> >>>>enough? Or >>>> >>should we limit new features to things that we decide are=20 >>>>"required." >>>> > >>>> > >>>> > Well, the max-receive is required, and I think it is very=20 >>>>useful. As I wrote earlier, the question is if it should=20 >>> >>be possible=20 >> >>>>to indicate separate values for different media types. >>>> > >>>> > The max-send is not required, but I still think it=20 >>> >>would be very=20 >> >>>>useful. Earlier I gave some examples I think are very=20 >>> >>valid (nodes may=20 >> >>>>try to reserve memory according to how much big messages then can=20 >>>>expect to receive, redirection/forking may be done based on the=20 >>>>information etc etc etc). It wouldn't have any impacts on=20 >>> >>the protocol=20 >> >>>>functionality itself, and there would be no interop problems with=20 >>>>nodes that don't understand the max-send=20 >>> >>attribute/parameter (or just=20 >> >>>>don't care about it). >>>> > >>>> > Regards, >>>> > >>>> > Christer Holmberg >>>> > Ericsson Finland >>>> > >>>> > >>>> > >>>> >>hisham.khartabil@nokia.com wrote: >>>> >> >>>> >> >>>> >>>I think max-receive is useful, but not max-send. >>>> >>> >>>> >>>/Hisham >>>> >>> >>>> >>> >>>> >>> >>>> >>>>-----Original Message----- >>>> >>>>From: simple-bounces@ietf.org >>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>> >>>>Of ext Ben Campbell >>>> >>>>Sent: 25.May.2004 17:49 >>>> >>>>To: Christer Holmberg (JO/LMF) >>>> >>>>Cc: 'simple@ietf.org' >>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication >>>> >>>> >>>> >>>> >>>> >>>>(Oops, itchy trigger finger--ignore my last mail=20 >>> >>on the subject.) >> >>>> >>>> >>>> >>>>I do not have strong feelings on this as a=20 >>> >>requirement. If we >> >>>> >>>>do want to >>>> >>>>do it, the general approach seems good at the first read,=20 >>>>anyway. I >>>> >>>>don't think there is a need for the non-type specific size >>>> >> >>>> >>attribute. >>>> >> >>>> >>>>The only advantage would be to reduce size of the SDP. I >>>> >>>>don't see that >>>> >>>>as a big requirement, since it normally only happens one >>>> >> >>>> >>per session. >>>> >> >>>> >>>>Do others have thoughts on the matter? Do we need this >>>> >> >>>> >>feature at all? >>>> >> >>>> >>>> >>>> >>>> >>>> >>>>Christer Holmberg (JO/LMF) wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hi, >>>> >>>>> >>>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I >>>> >>>> >>>> >>>>am bringing to the list the issue about being able to >>>> >>>>indicate the max content size a node is able to receive. >>>> >>>>Also, as input, in chapter 4 of >>>> =20 >>>> >>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is >>>>> >>>> >>>>a requirement for such functionality: >>>> >>>> >>>> >>>> >>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum >>>> >>>> >>>> >>>>message size it is willing to receive. >>>> >>>> >>>> >>>> >>>> >>>>>I think it would be useful if clients could indicate the >>>> >>>> >>>> >>>>maximum payload size he is able to receive, and also send, >>>> >>>>either per type or stream. Note that I am talking about the >>>> >>>>total message/content size, not the size of individual >>>> >>>>fragments (the spec does say that messages bigger than 2k >>>> >>>>should be fragmented). >>>> >>>> >>>> >>>> >>>> >>>>>If the max size is dependent on the media type, max size >>>> >>>> >>>> >>>>could be defined as a accept-type token paramter: >>>> >>>> >>>> >>>> >>>> >>>>>example: >>>> >>>>> >>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, >>>> >>>> >>>> >>>>Y;max-send=3D2000;max-receive=3D500 >>>> >>>> >>>> >>>> >>>> >>>>>And, if the message size it not type dependent,=20 >>> >>generic max >> >>>> >>>> >>>> >>>>size attributes could be used. >>>> >>>> >>>> >>>> >>>> >>>>>example: >>>> >>>>> >>>> >>>>>a=3Dmax-send: 1000 >>>> >>>>>a=3Dmax-receive:1000 >>>> >>>>> >>>> >>>>>Even if one is not going to send more than the other party >>>> >>>> >>>> >>>>indicates he is able to receive I still think it=20 >>> >>is important >> >>>> >>>>that a node can indicate how much he is able to send. For >>>> >>>>example, the remote node may reserve memory=20 >>> >>according to that >> >>>> >>>>information, and/or intermediate proxies may do >>>> >>>>forking/routing based on the client capabilities. >>>> >>>> >>>> >>>> >>>> >>>>>An MSRP "message size too big" error code could also be >>>> >>>> >>>> >>>>useful, if a node for whatever reason is not able=20 >>> >>to accept a >> >>>> >>>>SEND message. This may be due to that the remote node is >>>> >>>>sending more data than was agreed in the offer/answer, but >>>> >>>>also due to that the receiving node for a short=20 >>> >>period isn't >> >>>> >>>>able to receive the agreed data size (if the max=20 >>> >>size change >> >>>> >>>>is permanent a new offer should of course be sent,=20 >>> >>instead of >> >>>> >>>>sending an error reply to every SEND). At the=20 >>> >>interim meeting >> >>>> >>>>is was desired to have a mechanism to "interrupt" the >>>> >>>>receival of a message, and this error code could be used to >>>> >>>>indicate that. The sender would then stop sending the >>>> >>>>message, and any possible yet unsent fragments. >>>> >>>> >>>> >>>> >>>> >>>>>Regards, >>>> >>>>> >>>> >>>>>Christer Holmberg >>>> >>>>>Ericsson Finland >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>> >>>>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 >>>> >>>> >>>> >>>>This message has been scanned for viruses by MailControl -=20 >>>>www.mailcontrol.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 >>> >> >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 15:04:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06228 for ; Mon, 7 Jun 2004 15:04:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPQQ-0006d3-Fo for simple-archive@ietf.org; Mon, 07 Jun 2004 15:04:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPON-0005tl-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 15:02:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXPMT-0004s2-00; Mon, 07 Jun 2004 15:00:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXPJJ-0007CW-KL; Mon, 07 Jun 2004 14:57:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXPDJ-0006s5-C8; Mon, 07 Jun 2004 14:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXP68-0004tv-D2 for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:43: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 OAA04944 for ; Mon, 7 Jun 2004 14:43:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXP67-0003Wi-8y for simple@ietf.org; Mon, 07 Jun 2004 14:43:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXP58-0002yd-00 for simple@ietf.org; Mon, 07 Jun 2004 14:42:51 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BXP4E-0002R5-00 for simple@ietf.org; Mon, 07 Jun 2004 14:41:54 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57IfoWR018754 for ; Mon, 7 Jun 2004 20:41:53 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 20:41:50 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 20:41:50 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Mon, 7 Jun 2004 20:41:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jun 2004 18:41:50.0812 (UTC) FILETIME=[189551C0:01C44CBF] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Paul, >You say this is all optional. But then you say that some=20 >nodes will make use of sender maximum size to allocate resources on = the=20 >receiving node. So what happens when the sender doesn't specify? >=20 >1) sender specifies nothing, receiver assumes worst case. >(The most it could possibly receive.) How is this >better than doing nothing? [CHH] If the sender doesn't specify anything I guess the message size = is not very critical for him. The receiver, if then receiving too large = messages (the sender doesn't understand the attribute/parameter if sent = by the receiver), can then reject them using a suitable 4xx response = code. But, the idea it to avoid these kind of situations. As I've said before, intermediate proxies may use the information for = routing, to find the "best" receiver, or the receiver may have reserved = more memory from the beginning (it may for example have refused or shut = down some other services, in order to get more memory). >2) sender specifies nothing, receiver picks something >less than worst case. Then there are things the >sender won't be able to send that could have been >sent had the sender requested so in advance. Not nice. [CHH] Of course there may be good and bad mechanisms for clients to = choose a value, and if a node chooses a much lower value than it = actually would be able to handle it's not very nice, and there is then = a chance that nothing will be sent. However, the main reason for a node = to insert a value is because it does have limited memory (or, it will = reserve memory according to what it indicates), not just "for fun". >I'm not opposed to investigating it further. But I do agree with Ben=20 >that it is likely to slow things down. And if you intend for it to be=20 >optional then it should be no problem to add later. [CHH] I really don't see how this would slow things down. Again, I see = no needs to define how to handle = one-node-supporting-and-one-node-not-supporting scenarios, because if = one node doesn't support the information just won't be available. Regards, Christer Holmberg Ericsson Finland >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > > I disagree, and my answer is yes/yes. > >=20 > >=20 > >>I'm inclined to agree with you (no/no). For many nodes this=20 > is simply=20 > >>not a number that is easily decided. If anything, I imagine=20 > >>it would be best to negotiate this. But that requires the=20 > sender to pick=20 > >>a maximum send value, even though the sender probably has=20 > no particular limit.=20 > >>This just seems like a rat hole best avoided for now. > >=20 > >=20 > > The support and use of the attribute/parameter would be=20 > OPTIONAL, so if a node doesn't support the=20 > attribute/parameter (it is not able to calculate a value, it=20 > can't be configured, or the node simply thinks that size=20 > doesn't matter) everything will still work, as today, and it=20 > will then be "local policy" what to do if the messages can't=20 > be handled. > >=20 > > Of course, a node can send a 4xx response if the message it=20 > receives is too big, but as I said before, there may be=20 > scenarios where the size information is used to make=20 > decissions already at the session setup phase. > >=20 > > As Andrew said, this feature is especially useful for=20 > mobile devices, or other nodes with limited memory. > >=20 > > And, since there is a requirement at least for the=20 > receiving part, I assume it at some stage has been realized=20 > that the information could be useful. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: 7. kes=E4kuuta 2004 19:55 > >>To: Ben Campbell > >>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > >>simple@ietf.org; Christer > >>Holmberg (JO/LMF) > >>Subject: Re: [Simple] Re: MSRP: Max message size indication > >> > >> > >>Ben, > >> > >> > >> Paul > >> > >>Ben Campbell wrote: > >> > >>>I'd like to try and get some closure on this: > >>> > >>>Please answer yes or no to the following: > >>> > >>>1) Should we add the optional signaling of the maximum=20 > >> > >>content size you=20 > >> > >>>are willing to _receive_ into the SDP exchange. > >>> > >>>2) Should we add the optional signaling of the maximum=20 > >> > >>content size you=20 > >> > >>>are planning to _send_ into the SDP exchange. > >>> > >>>3) If either 1 or 2 is yes, do we send one value for the=20 > >> > >>session, or one=20 > >> > >>>value per each type for which we have indicated support. > >>> > >>>My personal opinions: > >>> > >>>No and No. In all honesty, I think this could be a useful=20 > >> > >>feature, but I=20 > >> > >>>don't think MSRP has to have it to function. I am voting=20 > >> > >>no, not because=20 > >> > >>>I disagree with the feature, but because I don't want to=20 > >> > >>add additional=20 > >> > >>>work to completing MSRP unless it is absolutely necessary. But if=20 > >>>consensus says we need it, I do not object on any technical basis. > >>> > >>> > >>> > >>> > >>>Chris Boulton wrote: > >>> > >>> > >>>>I think this feature would certainly be useful for max=20 > >>> > >>receive (if it=20 > >> > >>>>was type specific) BUT I am not convinced about send. > >>>>=20 > >>>>Chris. > >>>>=20 > >>>> > >>>> -----Original Message----- From: Ben Campbell=20 > >>>>[mailto:bcampbell@dynamicsoft.com] Sent: Tue 25/05/2004 18:27 = > >>>> To: Christer Holmberg (JO/LMF) Cc:=20 > >>> > >>hisham.khartabil@nokia.com;=20 > >> > >>>>simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > >>> > >>message size=20 > >> > >>>>indication > >>>> =20 > >>>> =20 > >>>> > >>>> Let me step up a level: > >>>> =20 > >>>> By the required vs useful discussion, I was referring to the=20 > >>>>feature of > >>>> being able to signal size limitations itself, rather=20 > than some=20 > >>>>aspect of > >>>> the feature. > >>>> =20 > >>>> So, what do others about whether the feature of being=20 > >>> > >>able to signal > >> > >>>> message size limits is required? > >>>> =20 > >>>> Christer Holmberg (JO/LMF) wrote: > >>>> =20 > >>>> > Hi, > >>>> > > >>>> > > >>>> >>(Ignore my yet-another-empty reply. This time I=20 > >>> > >>blame the combined > >> > >>>> >>ergonomics of Thunderbird and my laptop.) > >>>> >> > >>>> >>That brings up an interesting meta-question. What is the = bar > >>>> >>for putting new features into MSRP at this stage? Is=20 > >>> > >>"useful"=20 > >> > >>>>enough? Or > >>>> >>should we limit new features to things that we decide are=20 > >>>>"required." > >>>> > > >>>> > > >>>> > Well, the max-receive is required, and I think it is very=20 > >>>>useful. As I wrote earlier, the question is if it should=20 > >>> > >>be possible=20 > >> > >>>>to indicate separate values for different media types. > >>>> > > >>>> > The max-send is not required, but I still think it=20 > >>> > >>would be very=20 > >> > >>>>useful. Earlier I gave some examples I think are very=20 > >>> > >>valid (nodes may=20 > >> > >>>>try to reserve memory according to how much big messages then can = > >>>>expect to receive, redirection/forking may be done based on the=20 > >>>>information etc etc etc). It wouldn't have any impacts on=20 > >>> > >>the protocol=20 > >> > >>>>functionality itself, and there would be no interop problems with = > >>>>nodes that don't understand the max-send=20 > >>> > >>attribute/parameter (or just=20 > >> > >>>>don't care about it). > >>>> > > >>>> > Regards, > >>>> > > >>>> > Christer Holmberg > >>>> > Ericsson Finland > >>>> > > >>>> > > >>>> > > >>>> >>hisham.khartabil@nokia.com wrote: > >>>> >> > >>>> >> > >>>> >>>I think max-receive is useful, but not max-send. > >>>> >>> > >>>> >>>/Hisham > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>>>-----Original Message----- > >>>> >>>>From: simple-bounces@ietf.org > >>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>>> >>>>Of ext Ben Campbell > >>>> >>>>Sent: 25.May.2004 17:49 > >>>> >>>>To: Christer Holmberg (JO/LMF) > >>>> >>>>Cc: 'simple@ietf.org' > >>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >>>> >>>> > >>>> >>>> > >>>> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > >>> > >>on the subject.) > >> > >>>> >>>> > >>>> >>>>I do not have strong feelings on this as a=20 > >>> > >>requirement. If we > >> > >>>> >>>>do want to > >>>> >>>>do it, the general approach seems good at the first read, = > >>>>anyway. I > >>>> >>>>don't think there is a need for the non-type specific = size > >>>> >> > >>>> >>attribute. > >>>> >> > >>>> >>>>The only advantage would be to reduce size of the SDP. I > >>>> >>>>don't see that > >>>> >>>>as a big requirement, since it normally only happens one > >>>> >> > >>>> >>per session. > >>>> >> > >>>> >>>>Do others have thoughts on the matter? Do we need this > >>>> >> > >>>> >>feature at all? > >>>> >> > >>>> >>>> > >>>> >>>> > >>>> >>>>Christer Holmberg (JO/LMF) wrote: > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> >>>>>Hi, > >>>> >>>>> > >>>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion = I > >>>> >>>> > >>>> >>>>am bringing to the list the issue about being able to > >>>> >>>>indicate the max content size a node is able to receive. > >>>> >>>>Also, as input, in chapter 4 of > >>>> =20 > >>>> > >>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >>>>> > >>>> >>>>a requirement for such functionality: > >>>> >>>> > >>>> >>>> > >>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >>>> >>>> > >>>> >>>>message size it is willing to receive. > >>>> >>>> > >>>> >>>> > >>>> >>>>>I think it would be useful if clients could indicate the > >>>> >>>> > >>>> >>>>maximum payload size he is able to receive, and also = send, > >>>> >>>>either per type or stream. Note that I am talking=20 > about the > >>>> >>>>total message/content size, not the size of individual > >>>> >>>>fragments (the spec does say that messages bigger than 2k > >>>> >>>>should be fragmented). > >>>> >>>> > >>>> >>>> > >>>> >>>>>If the max size is dependent on the media type, max size > >>>> >>>> > >>>> >>>>could be defined as a accept-type token paramter: > >>>> >>>> > >>>> >>>> > >>>> >>>>>example: > >>>> >>>>> > >>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >>>> >>>> > >>>> >>>>Y;max-send=3D2000;max-receive=3D500 > >>>> >>>> > >>>> >>>> > >>>> >>>>>And, if the message size it not type dependent,=20 > >>> > >>generic max > >> > >>>> >>>> > >>>> >>>>size attributes could be used. > >>>> >>>> > >>>> >>>> > >>>> >>>>>example: > >>>> >>>>> > >>>> >>>>>a=3Dmax-send: 1000 > >>>> >>>>>a=3Dmax-receive:1000 > >>>> >>>>> > >>>> >>>>>Even if one is not going to send more than the=20 > other party > >>>> >>>> > >>>> >>>>indicates he is able to receive I still think it=20 > >>> > >>is important > >> > >>>> >>>>that a node can indicate how much he is able to send. For > >>>> >>>>example, the remote node may reserve memory=20 > >>> > >>according to that > >> > >>>> >>>>information, and/or intermediate proxies may do > >>>> >>>>forking/routing based on the client capabilities. > >>>> >>>> > >>>> >>>> > >>>> >>>>>An MSRP "message size too big" error code could also be > >>>> >>>> > >>>> >>>>useful, if a node for whatever reason is not able=20 > >>> > >>to accept a > >> > >>>> >>>>SEND message. This may be due to that the remote node is > >>>> >>>>sending more data than was agreed in the offer/answer, = but > >>>> >>>>also due to that the receiving node for a short=20 > >>> > >>period isn't > >> > >>>> >>>>able to receive the agreed data size (if the max=20 > >>> > >>size change > >> > >>>> >>>>is permanent a new offer should of course be sent,=20 > >>> > >>instead of > >> > >>>> >>>>sending an error reply to every SEND). At the=20 > >>> > >>interim meeting > >> > >>>> >>>>is was desired to have a mechanism to "interrupt" the > >>>> >>>>receival of a message, and this error code could=20 > be used to > >>>> >>>>indicate that. The sender would then stop sending the > >>>> >>>>message, and any possible yet unsent fragments. > >>>> >>>> > >>>> >>>> > >>>> >>>>>Regards, > >>>> >>>>> > >>>> >>>>>Christer Holmberg > >>>> >>>>>Ericsson Finland > >>>> >>>> > >>>> >>>> > >>>> >>>>_______________________________________________ > >>>> >>>>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 > >>>> > >>>> > >>>> > >>>>This message has been scanned for viruses by MailControl -=20 > >>>>www.mailcontrol.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 > >>> > >> > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 15:05:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06326 for ; Mon, 7 Jun 2004 15:05:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPQl-0006fv-Un for simple-archive@ietf.org; Mon, 07 Jun 2004 15:05:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPOp-0005y4-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 15:03:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXPMc-0004sC-00; Mon, 07 Jun 2004 15:00:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXPAv-0006AK-MY; Mon, 07 Jun 2004 14:48:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXP09-0003Ou-P8; Mon, 07 Jun 2004 14:37:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOtH-00011C-LF for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:30: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 OAA04129 for ; Mon, 7 Jun 2004 14:30:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOtG-0004HN-GU for simple@ietf.org; Mon, 07 Jun 2004 14:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOrH-0003Hq-00 for simple@ietf.org; Mon, 07 Jun 2004 14:28:32 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BXOqC-0002cP-00 for simple@ietf.org; Mon, 07 Jun 2004 14:27:24 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57IROPA029759 for ; Mon, 7 Jun 2004 20:27:24 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 20:27:23 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 20:27:23 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Corby.Wilson@nokia.com'" , pkyzivat@cisco.com, bcampbell@dynamicsoft.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Mon, 7 Jun 2004 20:27:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jun 2004 18:27:23.0895 (UTC) FILETIME=[13DC4870:01C44CBD] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Corby, >I would say yes/yes as well, but it would be at session=20 >initiation. Since the limit selected would be platform=20 >dependent it does not make sense to send the max on every message. Correct. Of course, one COULD include it in an updated offer, if the = size limit for whatever reason changes. But again, nodes that don't = support the attribute/parameter would simply ignore it. >The supporting point here is that allowing small terminals to=20 >speed things up a bit by letting the terminal transmit=20 >capabilities to the peer to make things easier is a definite plus. Exactly. Regards, Christer Holmberg Ericsson Finland >=20 > I agree with Christer that this should be an OPTION only. >=20 > Corby Wilson > Nokia >=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of ext Christer=20 > Holmberg (JO/LMF) > Sent: Monday, June 07, 2004 1:23 PM > To: 'Paul Kyzivat'; Ben Campbell > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Chris Boulton;=20 > simple@ietf.org > Subject: RE: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Hi, >=20 > I disagree, and my answer is yes/yes. >=20 > >I'm inclined to agree with you (no/no). For many nodes this=20 > is simply=20 > >not a number that is easily decided. If anything, I imagine=20 > >it would be best to negotiate this. But that requires the=20 > sender to pick=20 > >a maximum send value, even though the sender probably has no=20 > particular limit.=20 > >This just seems like a rat hole best avoided for now. >=20 > The support and use of the attribute/parameter would be=20 > OPTIONAL, so if a node doesn't support the=20 > attribute/parameter (it is not able to calculate a value, it=20 > can't be configured, or the node simply thinks that size=20 > doesn't matter) everything will still work, as today, and it=20 > will then be "local policy" what to do if the messages can't=20 > be handled. >=20 > Of course, a node can send a 4xx response if the message it=20 > receives is too big, but as I said before, there may be=20 > scenarios where the size information is used to make=20 > decissions already at the session setup phase. >=20 > As Andrew said, this feature is especially useful for mobile=20 > devices, or other nodes with limited memory. >=20 > And, since there is a requirement at least for the receiving=20 > part, I assume it at some stage has been realized that the=20 > information could be useful. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 7. kes=E4kuuta 2004 19:55 > > To: Ben Campbell > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > simple@ietf.org; Christer > > Holmberg (JO/LMF) > > Subject: Re: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > > Ben, > >=20 > >=20 > > Paul > >=20 > > Ben Campbell wrote: > > > I'd like to try and get some closure on this: > > >=20 > > > Please answer yes or no to the following: > > >=20 > > > 1) Should we add the optional signaling of the maximum=20 > > content size you=20 > > > are willing to _receive_ into the SDP exchange. > > >=20 > > > 2) Should we add the optional signaling of the maximum=20 > > content size you=20 > > > are planning to _send_ into the SDP exchange. > > >=20 > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > session, or one=20 > > > value per each type for which we have indicated support. > > >=20 > > > My personal opinions: > > >=20 > > > No and No. In all honesty, I think this could be a useful=20 > > feature, but I=20 > > > don't think MSRP has to have it to function. I am voting=20 > > no, not because=20 > > > I disagree with the feature, but because I don't want to=20 > > add additional=20 > > > work to completing MSRP unless it is absolutely necessary. But if = > > > consensus says we need it, I do not object on any technical = basis. > > >=20 > > >=20 > > >=20 > > >=20 > > > Chris Boulton wrote: > > >=20 > > >> I think this feature would certainly be useful for max=20 > > receive (if it=20 > > >> was type specific) BUT I am not convinced about send. > > >> =20 > > >> Chris. > > >> =20 > > >> > > >> -----Original Message----- From: Ben Campbell=20 > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > 25/05/2004 18:27=20 > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > hisham.khartabil@nokia.com;=20 > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > message size=20 > > >> indication > > >> =20 > > >> =20 > > >> > > >> Let me step up a level: > > >> =20 > > >> By the required vs useful discussion, I was referring to the = > > >> feature of > > >> being able to signal size limitations itself, rather=20 > than some=20 > > >> aspect of > > >> the feature. > > >> =20 > > >> So, what do others about whether the feature of being=20 > > able to signal > > >> message size limits is required? > > >> =20 > > >> Christer Holmberg (JO/LMF) wrote: > > >> =20 > > >> > Hi, > > >> > > > >> > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > blame the combined > > >> >>ergonomics of Thunderbird and my laptop.) > > >> >> > > >> >>That brings up an interesting meta-question. What=20 > is the bar > > >> >>for putting new features into MSRP at this stage? Is=20 > > "useful"=20 > > >> enough? Or > > >> >>should we limit new features to things that we decide are=20 > > >> "required." > > >> > > > >> > > > >> > Well, the max-receive is required, and I think it is very=20 > > >> useful. As I wrote earlier, the question is if it should=20 > > be possible=20 > > >> to indicate separate values for different media types. > > >> > > > >> > The max-send is not required, but I still think it=20 > > would be very=20 > > >> useful. Earlier I gave some examples I think are very=20 > > valid (nodes may=20 > > >> try to reserve memory according to how much big messages=20 > then can=20 > > >> expect to receive, redirection/forking may be done based on the=20 > > >> information etc etc etc). It wouldn't have any impacts on=20 > > the protocol=20 > > >> functionality itself, and there would be no interop=20 > problems with=20 > > >> nodes that don't understand the max-send=20 > > attribute/parameter (or just=20 > > >> don't care about it). > > >> > > > >> > Regards, > > >> > > > >> > Christer Holmberg > > >> > Ericsson Finland > > >> > > > >> > > > >> > > > >> >>hisham.khartabil@nokia.com wrote: > > >> >> > > >> >> > > >> >>>I think max-receive is useful, but not max-send. > > >> >>> > > >> >>>/Hisham > > >> >>> > > >> >>> > > >> >>> > > >> >>>>-----Original Message----- > > >> >>>>From: simple-bounces@ietf.org > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > >> >>>>Of ext Ben Campbell > > >> >>>>Sent: 25.May.2004 17:49 > > >> >>>>To: Christer Holmberg (JO/LMF) > > >> >>>>Cc: 'simple@ietf.org' > > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > > >> >>>> > > >> >>>> > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > on the subject.) > > >> >>>> > > >> >>>>I do not have strong feelings on this as a=20 > > requirement. If we > > >> >>>>do want to > > >> >>>>do it, the general approach seems good at the=20 > first read,=20 > > >> anyway. I > > >> >>>>don't think there is a need for the non-type=20 > specific size > > >> >> > > >> >>attribute. > > >> >> > > >> >>>>The only advantage would be to reduce size of the SDP. I > > >> >>>>don't see that > > >> >>>>as a big requirement, since it normally only happens one > > >> >> > > >> >>per session. > > >> >> > > >> >>>>Do others have thoughts on the matter? Do we need this > > >> >> > > >> >>feature at all? > > >> >> > > >> >>>> > > >> >>>> > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>>>Hi, > > >> >>>>> > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > discussion I > > >> >>>> > > >> >>>>am bringing to the list the issue about being able to > > >> >>>>indicate the max content size a node is able to receive. > > >> >>>>Also, as input, in chapter 4 of > > >> =20 > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > >> >>>>a requirement for such functionality: > > >> >>>> > > >> >>>> > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the = maximum > > >> >>>> > > >> >>>>message size it is willing to receive. > > >> >>>> > > >> >>>> > > >> >>>>>I think it would be useful if clients could indicate = the > > >> >>>> > > >> >>>>maximum payload size he is able to receive, and=20 > also send, > > >> >>>>either per type or stream. Note that I am=20 > talking about the > > >> >>>>total message/content size, not the size of individual > > >> >>>>fragments (the spec does say that messages bigger than = 2k > > >> >>>>should be fragmented). > > >> >>>> > > >> >>>> > > >> >>>>>If the max size is dependent on the media type, max = size > > >> >>>> > > >> >>>>could be defined as a accept-type token paramter: > > >> >>>> > > >> >>>> > > >> >>>>>example: > > >> >>>>> > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > >> >>>> > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > >> >>>> > > >> >>>> > > >> >>>>>And, if the message size it not type dependent,=20 > > generic max > > >> >>>> > > >> >>>>size attributes could be used. > > >> >>>> > > >> >>>> > > >> >>>>>example: > > >> >>>>> > > >> >>>>>a=3Dmax-send: 1000 > > >> >>>>>a=3Dmax-receive:1000 > > >> >>>>> > > >> >>>>>Even if one is not going to send more than the=20 > other party > > >> >>>> > > >> >>>>indicates he is able to receive I still think it=20 > > is important > > >> >>>>that a node can indicate how much he is able to send. = For > > >> >>>>example, the remote node may reserve memory=20 > > according to that > > >> >>>>information, and/or intermediate proxies may do > > >> >>>>forking/routing based on the client capabilities. > > >> >>>> > > >> >>>> > > >> >>>>>An MSRP "message size too big" error code could also be > > >> >>>> > > >> >>>>useful, if a node for whatever reason is not able=20 > > to accept a > > >> >>>>SEND message. This may be due to that the remote node is > > >> >>>>sending more data than was agreed in the=20 > offer/answer, but > > >> >>>>also due to that the receiving node for a short=20 > > period isn't > > >> >>>>able to receive the agreed data size (if the max=20 > > size change > > >> >>>>is permanent a new offer should of course be sent,=20 > > instead of > > >> >>>>sending an error reply to every SEND). At the=20 > > interim meeting > > >> >>>>is was desired to have a mechanism to "interrupt" the > > >> >>>>receival of a message, and this error code could=20 > be used to > > >> >>>>indicate that. The sender would then stop sending the > > >> >>>>message, and any possible yet unsent fragments. > > >> >>>> > > >> >>>> > > >> >>>>>Regards, > > >> >>>>> > > >> >>>>>Christer Holmberg > > >> >>>>>Ericsson Finland > > >> >>>> > > >> >>>> > > >> >>>>_______________________________________________ > > >> >>>>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 > > >> > > >> > > >> > > >> This message has been scanned for viruses by MailControl -=20 > > >> www.mailcontrol.com > > >> > > >> > > >> > > >>=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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 15:05:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06407 for ; Mon, 7 Jun 2004 15:05:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPR6-0006sZ-Gk for simple-archive@ietf.org; Mon, 07 Jun 2004 15:05:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPP3-00060M-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 15:03:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXPMi-0004sC-01; Mon, 07 Jun 2004 15:01:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXP7X-0005q6-II; Mon, 07 Jun 2004 14:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOzF-0003Gd-Fi; Mon, 07 Jun 2004 14:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOpM-0000kM-NN for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:26: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 OAA03945 for ; Mon, 7 Jun 2004 14:26:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOpL-0002ES-IL for simple@ietf.org; Mon, 07 Jun 2004 14:26:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOoP-0001i7-00 for simple@ietf.org; Mon, 07 Jun 2004 14:25:34 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXOnT-0001Ap-00 for simple@ietf.org; Mon, 07 Jun 2004 14:24:35 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57IOYAh011686 for ; Mon, 7 Jun 2004 20:24:34 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 20:24:34 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 20:24:34 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" Subject: RE: [Simple] MSRP: Ending a session Date: Mon, 7 Jun 2004 20:24:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 07 Jun 2004 18:24:34.0877 (UTC) FILETIME=[AF1E2ED0:01C44CBC] Cc: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Paul, Comments inline ([CHH]) >Obviously you can't force anybody to do anything. If they want to cut >you off in mid conversation then that is what they will do, just like >hanging up on you in a conversation. But its not polite. > >In some sense the situation is no different with MSRP than it is with >voice and RTP. However I think MSRP exposes issues that are >small enough to ignore with voice. In particular, with voice, if you lose a small >number of packets typically nobody cares, because with voice there is >little information content in a small number of packets. But >with MSRP, a "packet" (message) can have substantial content, so that whether it >gets thru or not can have considerable significance. > >This will be true in all sorts of call flows, such as >transfers, and is true here at the end of a session. So we should be defining >mechanisms that can work gracefully, without loss of messages. Whether >people use them that way is up to them. [CHH] Of course, there may be scenarios where it's good, or even required, to wait for the release response. So, the draft could say that a node MAY do so. But, at the same time we sould respect the SIP core rules, and not defining behaviour which overrides those. Otherwise things will get very messy, and things may get out of hand when new extensions, features and/or media types are defined... >Also, I see many people talk as if BYE was the only way to >end an MSRP session. But it is not. It may be ended simply by sending a >reINVITE (or UPDATE) that drops the MSRP stream (by setting the port >number to zero). > >This may not be a very useful thing to do when MSRP is the >only medium in use, but it can make a lot of sense when there are other >media. For instance, I might start in an IM session, then decide to add >voice. Once voice has been added, I may just close my IM window, killing the MSRP >stream. > >In a case like that there is more lattitude to keep the state of the >stream until all the signaling to kill it is complete. For instance, >when I close my IM window that can implicitly initiate the >reinvite to drop the stream. But even though the window disappears, its state can >remain. If another incoming message is received, the window can be >popped again to show it to me. [CHH] That is true. And RFC3264 (offer/answer) says that the parameters in an updated offer won't replace the old ones before an answer has been received. However, even then, in the special case when someone removes a stream by setting the port to zero, I am pretty sure the media resources (wether it's RTP or MSRP) in many cases are "gone", no matter if the other party accepts the offer or not. But again, of course one may keep state and resources until the answer is received, if there is a reason/possibility to do so. But, this are generic offer/answer rules, and again I don't think we should avoid re-defining them. Regards, Christer Holmberg Ericsson Finland > > Paul > > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > Chapter 6.5.4 in the MSRP draft (version -06) says: > > > > "When either endpoint in an MSRP session wishes to end the > session, it > > first signals its intent using the normal processing for the > > signaling protocol. For example, in SIP, it would send a > BYE request > > to the peer. After agreeing to end the session, the host endpoint > > MUST release any resources acquired as part of the session." > > > > Later in the chapter it is also described how possible > outstanding MSRP transactions > > are handled when a session is to be released. > > > > Now, I don't think it should be a must for a node to wait > for a node to receive the BYE response before the TCP > resources are released. Many nodes releases the media > resources at the same time as the BYE is sent. And, even if > would keep the connection open for possible outstanding MSRP > transactions they would most likely be "lost" anyway, since a > user will not (in gateway scenarios may not even be able to) > wait for possible messages after the release message is sent. > > > > Also, chapter 15.1.1 in RFC3261 says: > > > > "Once the BYE is constructed, the UAC core creates a new non-INVITE > > client transaction, and passes it the BYE request. The UAC MUST > > consider the session terminated (and therefore stop sending or > > listening for media) as soon as the BYE request is passed to the > > client transaction." > > > > To me this clearly indicates that a node does not need to > keep resources and wait for anything after the BYE is sent. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > _______________________________________________ > > 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-bounces@ietf.org Mon Jun 7 15:07:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06706 for ; Mon, 7 Jun 2004 15:07:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPSh-00005w-Ic for simple-archive@ietf.org; Mon, 07 Jun 2004 15:07:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPRb-0007Gg-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 15:06:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXPPn-00062i-00; Mon, 07 Jun 2004 15:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXPGS-0007Vo-1h; Mon, 07 Jun 2004 14:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXP9l-0005th-6C for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:47: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 OAA05288 for ; Mon, 7 Jun 2004 14:47:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXP9j-0005fq-V5 for simple@ietf.org; Mon, 07 Jun 2004 14:47:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXP8g-00050F-00 for simple@ietf.org; Mon, 07 Jun 2004 14:46:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BXP6c-0003Ww-00 for simple@ietf.org; Mon, 07 Jun 2004 14:44:22 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Jun 2004 14:47:39 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i57Ihopp006174; Mon, 7 Jun 2004 14:43:50 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-2-76.cisco.com [10.86.242.76]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJF00619; Mon, 7 Jun 2004 14:43:49 -0400 (EDT) Message-ID: <40C4B765.1040005@cisco.com> Date: Mon, 07 Jun 2004 14:43:49 -0400 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: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] MSRP: updated offer on transaction timeout or non-2x x/415 respons e References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: > >>Assuming you don't have reason to change something else, it would be >>sufficient to simply change the 'resource' portion of the msrp url. > > [CHH] I guess it would be good to clarify that in the draft. Yeah, I guess it would, though it is implicit once you realize you have to change something. If you prefer you may change the port, or some other part of the address. Hmm. I wonder if it would be sufficient to change something in the offer that is ignored, like the port in the m-line or the address in the c-line? I suppose that wouldn't be ideal, because it would require paying attention to stuff that is ignored. > Of course, there is also the case where there is no resource portion used (since it's optional), so I guess in that case it would have to be mandatory to include the resource portion in the updated offer. This falls into the category of "if it hurts, don't do it". Omitting the resource part only works if you only have one resource. >>Also, does the node really need to send an updated SDP in >>the first place, if the IP parameters don't change? Why not >>just trying to re-establish the TCP connection? >> >>1) because permitting this would require that a tcp listener >>always be active just in case this should happen. This could be a >>burden for some nodes. > > [CHH] That's a good point. > > However, doesn't a SIP node have to have the listener active always anyway, for incoming SIP requests (if TCP is used), since there is no requirement (it may be recommended, though) to keep a connection open for the whole session? - the node where the media is terminated may be different from the place where the sip signaling is terminated - I really don't think you want to use the same port to listen for sip and MSRP connections. How would you know which protocol is to be used on the connection? While you could wait for the first message, that seems like a bad idea. >>2) because an attempt to establish a connection when one is already >>active is interpretted as an attack. > > [CHH] The offerer would tear down the old connection before establishing the new one, in the same way it would do when receiving an answer to an updated offer. There are at obscure race conditions and failure modes here. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 7 15:19:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08375 for ; Mon, 7 Jun 2004 15:19:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPew-0007Ix-GS for simple-archive@ietf.org; Mon, 07 Jun 2004 15:19:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPdn-0006fp-00 for simple-archive@ietf.org; Mon, 07 Jun 2004 15:18:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXPbT-00050j-00; Mon, 07 Jun 2004 15:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXPRF-0006sz-Ae; Mon, 07 Jun 2004 15:05:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXPIP-0007yx-DQ for simple@megatron.ietf.org; Mon, 07 Jun 2004 14:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05817 for ; Mon, 7 Jun 2004 14:56:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPIO-0002lq-5R for simple@ietf.org; Mon, 07 Jun 2004 14:56:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPHX-0002Gq-00 for simple@ietf.org; Mon, 07 Jun 2004 14:55:40 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXPGp-0001l7-00 for simple@ietf.org; Mon, 07 Jun 2004 14:54:56 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i57IstAh013727 for ; Mon, 7 Jun 2004 20:54:55 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 20:54:55 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 20:54:55 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" Subject: RE: [Simple] MSRP: updated offer on transaction timeout or non-2x x/415 respons e Date: Mon, 7 Jun 2004 20:54:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 07 Jun 2004 18:54:55.0775 (UTC) FILETIME=[EC752AF0:01C44CC0] Cc: "'simple@ietf.org'" , "'bcampbell@dynamicsoft.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Paul, >>>Assuming you don't have reason to change something else, it >>>would be sufficient to simply change the 'resource' portion of the msrp url. >> >>[CHH] I guess it would be good to clarify that in the draft. > >Yeah, I guess it would, though it is implicit once you >realize you have to change something. If you prefer you may change the port, or some >other part of the address. > >Hmm. I wonder if it would be sufficient to change something >in the offer that is ignored, like the port in the m-line or the address in the >c-line? I suppose that wouldn't be ideal, because it would require >paying attention to stuff that is ignored. [CHH] That would solve the what-if-there-is-no-resource-portion problem. >>Of course, there is also the case where there is no >>resource portion used (since it's optional), so I guess in >>that case it would have to be mandatory to include the >>resource portion in the updated offer. >This falls into the category of "if it hurts, don't do it". >Omitting the resource part only works if you only have one resource. [CHH] It depends on how you define "resource". Your one one only resource may be a single TCP socket, or the ability to handle one MSRP session at a time, but that would still be true even if you send a new offer. >>>Also, does the node really need to send an updated SDP in >>>the first place, if the IP parameters don't change? Why not >>>just trying to re-establish the TCP connection? >>> >>>1) because permitting this would require that a tcp listener >>>always be active just in case this should happen. This could be a >>>burden for some nodes. >> >>[CHH] That's a good point. >> >>However, doesn't a SIP node have to have the listener >>active always anyway, for incoming SIP requests (if TCP is >>used), since there is no requirement (it may be recommended, >>though) to keep a connection open for the whole session? > >- the node where the media is terminated may be different >from the place where the sip signaling is terminated > >- I really don't think you want to use the same port to >listen for sip and MSRP connections. How would you know which protocol is to >be used on the connection? While you could wait for the first message, >that seems like a bad idea. [CHH] I agree. I didn't think of using the same port, but of course it's heavier the more ports you have to listen to. >>>2) because an attempt to establish a connection when one is already >>>active is interpretted as an attack. >> >>[CHH] The offerer would tear down the old connection before >>establishing the new one, in the same way it would do when >>receiving an answer to an updated offer. >There are at obscure race conditions and failure modes here. Ok. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 04:06:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08922 for ; Tue, 8 Jun 2004 04:06:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXbco-0002y0-Rm for simple-archive@ietf.org; Tue, 08 Jun 2004 04:06:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXbbV-0002Fw-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 04:05:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXbaF-0000x7-00; Tue, 08 Jun 2004 04:03:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXbQw-000849-UE; Tue, 08 Jun 2004 03:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXbNG-0007R3-66 for simple@megatron.ietf.org; Tue, 08 Jun 2004 03:50:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08239 for ; Tue, 8 Jun 2004 03:50:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXbND-0007nq-Kq for simple@ietf.org; Tue, 08 Jun 2004 03:50:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXbM3-00076T-00 for simple@ietf.org; Tue, 08 Jun 2004 03:49:09 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BXbKw-0006F9-00 for simple@ietf.org; Tue, 08 Jun 2004 03:47:58 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i587lXJ22716; Tue, 8 Jun 2004 10:47:33 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 10:47:23 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i587lNSe032091; Tue, 8 Jun 2004 10:47:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00J3RoH4; Tue, 08 Jun 2004 10:47:23 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i587lMH08516; Tue, 8 Jun 2004 10:47:22 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 10:47:22 +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] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 10:47:22 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797BFC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication thread-index: AcRMtEUNAcjhDU/NQwaMToCHb+NxBwAd3fpQ To: , , X-OriginalArrivalTime: 08 Jun 2004 07:47:22.0440 (UTC) FILETIME=[D5390480:01C44D2C] Content-Transfer-Encoding: quoted-printable Cc: cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 07.June.2004 20:23 > To: 'Paul Kyzivat'; Ben Campbell > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > simple@ietf.org > Subject: RE: [Simple] Re: MSRP: Max message size indication >=20 >=20 >=20 > Hi, >=20 > I disagree, and my answer is yes/yes. >=20 > >I'm inclined to agree with you (no/no). For many nodes this=20 > is simply=20 > >not a number that is easily decided. If anything, I imagine=20 > >it would be best to negotiate this. But that requires the=20 > sender to pick=20 > >a maximum send value, even though the sender probably has no=20 > particular limit.=20 > >This just seems like a rat hole best avoided for now. >=20 > The support and use of the attribute/parameter would be=20 > OPTIONAL, so if a node doesn't support the=20 > attribute/parameter (it is not able to calculate a value, it=20 > can't be configured, or the node simply thinks that size=20 > doesn't matter) everything will still work, as today, and it=20 > will then be "local policy" what to do if the messages can't=20 > be handled. So, You send me an offer with receive-max-size of 1500 bytes, but I = don't understand that parameter. This doesn't help you. I send you a = message with 1Meg and you have to reject it with a 4xx anyway. So where = is the benefit of having this as optional? /Hisham >=20 > Of course, a node can send a 4xx response if the message it=20 > receives is too big, but as I said before, there may be=20 > scenarios where the size information is used to make=20 > decissions already at the session setup phase. >=20 > As Andrew said, this feature is especially useful for mobile=20 > devices, or other nodes with limited memory. >=20 > And, since there is a requirement at least for the receiving=20 > part, I assume it at some stage has been realized that the=20 > information could be useful. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 7. kes=E4kuuta 2004 19:55 > > To: Ben Campbell > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > simple@ietf.org; Christer > > Holmberg (JO/LMF) > > Subject: Re: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > > Ben, > >=20 > >=20 > > Paul > >=20 > > Ben Campbell wrote: > > > I'd like to try and get some closure on this: > > >=20 > > > Please answer yes or no to the following: > > >=20 > > > 1) Should we add the optional signaling of the maximum=20 > > content size you=20 > > > are willing to _receive_ into the SDP exchange. > > >=20 > > > 2) Should we add the optional signaling of the maximum=20 > > content size you=20 > > > are planning to _send_ into the SDP exchange. > > >=20 > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > session, or one=20 > > > value per each type for which we have indicated support. > > >=20 > > > My personal opinions: > > >=20 > > > No and No. In all honesty, I think this could be a useful=20 > > feature, but I=20 > > > don't think MSRP has to have it to function. I am voting=20 > > no, not because=20 > > > I disagree with the feature, but because I don't want to=20 > > add additional=20 > > > work to completing MSRP unless it is absolutely necessary. But if=20 > > > consensus says we need it, I do not object on any technical basis. > > >=20 > > >=20 > > >=20 > > >=20 > > > Chris Boulton wrote: > > >=20 > > >> I think this feature would certainly be useful for max=20 > > receive (if it=20 > > >> was type specific) BUT I am not convinced about send. > > >> =20 > > >> Chris. > > >> =20 > > >> > > >> -----Original Message----- From: Ben Campbell=20 > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > 25/05/2004 18:27=20 > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > hisham.khartabil@nokia.com;=20 > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > message size=20 > > >> indication > > >> =20 > > >> =20 > > >> > > >> Let me step up a level: > > >> =20 > > >> By the required vs useful discussion, I was referring to the=20 > > >> feature of > > >> being able to signal size limitations itself, rather=20 > than some=20 > > >> aspect of > > >> the feature. > > >> =20 > > >> So, what do others about whether the feature of being=20 > > able to signal > > >> message size limits is required? > > >> =20 > > >> Christer Holmberg (JO/LMF) wrote: > > >> =20 > > >> > Hi, > > >> > > > >> > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > blame the combined > > >> >>ergonomics of Thunderbird and my laptop.) > > >> >> > > >> >>That brings up an interesting meta-question. What=20 > is the bar > > >> >>for putting new features into MSRP at this stage? Is=20 > > "useful"=20 > > >> enough? Or > > >> >>should we limit new features to things that we decide are=20 > > >> "required." > > >> > > > >> > > > >> > Well, the max-receive is required, and I think it is very=20 > > >> useful. As I wrote earlier, the question is if it should=20 > > be possible=20 > > >> to indicate separate values for different media types. > > >> > > > >> > The max-send is not required, but I still think it=20 > > would be very=20 > > >> useful. Earlier I gave some examples I think are very=20 > > valid (nodes may=20 > > >> try to reserve memory according to how much big messages=20 > then can=20 > > >> expect to receive, redirection/forking may be done based on the=20 > > >> information etc etc etc). It wouldn't have any impacts on=20 > > the protocol=20 > > >> functionality itself, and there would be no interop=20 > problems with=20 > > >> nodes that don't understand the max-send=20 > > attribute/parameter (or just=20 > > >> don't care about it). > > >> > > > >> > Regards, > > >> > > > >> > Christer Holmberg > > >> > Ericsson Finland > > >> > > > >> > > > >> > > > >> >>hisham.khartabil@nokia.com wrote: > > >> >> > > >> >> > > >> >>>I think max-receive is useful, but not max-send. > > >> >>> > > >> >>>/Hisham > > >> >>> > > >> >>> > > >> >>> > > >> >>>>-----Original Message----- > > >> >>>>From: simple-bounces@ietf.org > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > >> >>>>Of ext Ben Campbell > > >> >>>>Sent: 25.May.2004 17:49 > > >> >>>>To: Christer Holmberg (JO/LMF) > > >> >>>>Cc: 'simple@ietf.org' > > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > > >> >>>> > > >> >>>> > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > on the subject.) > > >> >>>> > > >> >>>>I do not have strong feelings on this as a=20 > > requirement. If we > > >> >>>>do want to > > >> >>>>do it, the general approach seems good at the=20 > first read,=20 > > >> anyway. I > > >> >>>>don't think there is a need for the non-type=20 > specific size > > >> >> > > >> >>attribute. > > >> >> > > >> >>>>The only advantage would be to reduce size of the SDP. I > > >> >>>>don't see that > > >> >>>>as a big requirement, since it normally only happens one > > >> >> > > >> >>per session. > > >> >> > > >> >>>>Do others have thoughts on the matter? Do we need this > > >> >> > > >> >>feature at all? > > >> >> > > >> >>>> > > >> >>>> > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>>>Hi, > > >> >>>>> > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > discussion I > > >> >>>> > > >> >>>>am bringing to the list the issue about being able to > > >> >>>>indicate the max content size a node is able to receive. > > >> >>>>Also, as input, in chapter 4 of > > >> =20 > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > >> >>>>a requirement for such functionality: > > >> >>>> > > >> >>>> > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > > >> >>>> > > >> >>>>message size it is willing to receive. > > >> >>>> > > >> >>>> > > >> >>>>>I think it would be useful if clients could indicate the > > >> >>>> > > >> >>>>maximum payload size he is able to receive, and=20 > also send, > > >> >>>>either per type or stream. Note that I am=20 > talking about the > > >> >>>>total message/content size, not the size of individual > > >> >>>>fragments (the spec does say that messages bigger than 2k > > >> >>>>should be fragmented). > > >> >>>> > > >> >>>> > > >> >>>>>If the max size is dependent on the media type, max size > > >> >>>> > > >> >>>>could be defined as a accept-type token paramter: > > >> >>>> > > >> >>>> > > >> >>>>>example: > > >> >>>>> > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > >> >>>> > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > >> >>>> > > >> >>>> > > >> >>>>>And, if the message size it not type dependent,=20 > > generic max > > >> >>>> > > >> >>>>size attributes could be used. > > >> >>>> > > >> >>>> > > >> >>>>>example: > > >> >>>>> > > >> >>>>>a=3Dmax-send: 1000 > > >> >>>>>a=3Dmax-receive:1000 > > >> >>>>> > > >> >>>>>Even if one is not going to send more than the=20 > other party > > >> >>>> > > >> >>>>indicates he is able to receive I still think it=20 > > is important > > >> >>>>that a node can indicate how much he is able to send. For > > >> >>>>example, the remote node may reserve memory=20 > > according to that > > >> >>>>information, and/or intermediate proxies may do > > >> >>>>forking/routing based on the client capabilities. > > >> >>>> > > >> >>>> > > >> >>>>>An MSRP "message size too big" error code could also be > > >> >>>> > > >> >>>>useful, if a node for whatever reason is not able=20 > > to accept a > > >> >>>>SEND message. This may be due to that the remote node is > > >> >>>>sending more data than was agreed in the=20 > offer/answer, but > > >> >>>>also due to that the receiving node for a short=20 > > period isn't > > >> >>>>able to receive the agreed data size (if the max=20 > > size change > > >> >>>>is permanent a new offer should of course be sent,=20 > > instead of > > >> >>>>sending an error reply to every SEND). At the=20 > > interim meeting > > >> >>>>is was desired to have a mechanism to "interrupt" the > > >> >>>>receival of a message, and this error code could=20 > be used to > > >> >>>>indicate that. The sender would then stop sending the > > >> >>>>message, and any possible yet unsent fragments. > > >> >>>> > > >> >>>> > > >> >>>>>Regards, > > >> >>>>> > > >> >>>>>Christer Holmberg > > >> >>>>>Ericsson Finland > > >> >>>> > > >> >>>> > > >> >>>>_______________________________________________ > > >> >>>>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 > > >> > > >> > > >> > > >> This message has been scanned for viruses by MailControl -=20 > > >> www.mailcontrol.com > > >> > > >> > > >> > > >>=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-bounces@ietf.org Tue Jun 8 04:25:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09934 for ; Tue, 8 Jun 2004 04:25:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXbv6-0007Xh-Cw for simple-archive@ietf.org; Tue, 08 Jun 2004 04:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXbuD-0006rL-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 04:24:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXbtB-0005dT-00; Tue, 08 Jun 2004 04:23:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXboG-0004WQ-RH; Tue, 08 Jun 2004 04:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXbhj-0003BL-Mi for simple@megatron.ietf.org; Tue, 08 Jun 2004 04:11: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 EAA09266 for ; Tue, 8 Jun 2004 04:11:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXbhh-0006TD-F3 for simple@ietf.org; Tue, 08 Jun 2004 04:11:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXbgs-0005ni-00 for simple@ietf.org; Tue, 08 Jun 2004 04:10:40 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BXbfp-00056Z-00 for simple@ietf.org; Tue, 08 Jun 2004 04:09:33 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5889YPA025703 for ; Tue, 8 Jun 2004 10:09:34 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 10:09:34 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 10:09:34 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, bcampbell@dynamicsoft.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 10:09:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jun 2004 08:09:34.0369 (UTC) FILETIME=[EF1D4110:01C44D2F] Content-Transfer-Encoding: quoted-printable Cc: cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Hisham, >>The support and use of the attribute/parameter would be=20 >>OPTIONAL, so if a node doesn't support the=20 >>attribute/parameter (it is not able to calculate a value, it=20 >>can't be configured, or the node simply thinks that size=20 >>doesn't matter) everything will still work, as today, and it=20 >>will then be "local policy" what to do if the messages can't=20 >>be handled. >=20 >So, You send me an offer with receive-max-size of 1500 bytes,=20 >but I don't understand that parameter. This doesn't help you.=20 >I send you a message with 1Meg and you have to reject it with=20 >a 4xx anyway. So where is the benefit of having this as optional? The benefit is that you may have scenarios or network architectures = where this information is used (not only by the end terminals, but also = by intermediate nodes) for making service/routing/etc decissions. Of = course, a node may always send too large messages, which have to be = rejected (using a 4xx response), but the idea is to have a mechanism = where this can be avoided. If big messages are to be sent I think it is = very useful to have this information, in order to adjust terminal = settings, and to make the transmission smooth, and in order to send = lots of stuff on the network that may be rejected (that data may then = have to be retransmitted, using smaller messages, or the session may = fail). This is similar to any other SDP attribute. If you don't support it, = you discard it, and things should work anyway - but IF you support it = it may provide you with useful information for optimal performance. However, IF people prefear making support mandatory, I personally don't = have anything against that. But, that's not what I am proposing, = because I do realize there may be scenarios where this kind of = information is not needed. Another option is making it mandatory, and = defining a default value if the information is not present (similar to = the "sendrecv" media direction attribute), but that is not what I am = proposing either. My issue is that I think it's useful to have this = kind of information. Regards, Christer Holmberg Ericsson Finland >=20 > /Hisham >=20 > >=20 > > Of course, a node can send a 4xx response if the message it=20 > > receives is too big, but as I said before, there may be=20 > > scenarios where the size information is used to make=20 > > decissions already at the session setup phase. > >=20 > > As Andrew said, this feature is especially useful for mobile=20 > > devices, or other nodes with limited memory. > >=20 > > And, since there is a requirement at least for the receiving=20 > > part, I assume it at some stage has been realized that the=20 > > information could be useful. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 7. kes=E4kuuta 2004 19:55 > > > To: Ben Campbell > > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > > simple@ietf.org; Christer > > > Holmberg (JO/LMF) > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > >=20 > > >=20 > > > Ben, > > >=20 > > >=20 > > > Paul > > >=20 > > > Ben Campbell wrote: > > > > I'd like to try and get some closure on this: > > > >=20 > > > > Please answer yes or no to the following: > > > >=20 > > > > 1) Should we add the optional signaling of the maximum=20 > > > content size you=20 > > > > are willing to _receive_ into the SDP exchange. > > > >=20 > > > > 2) Should we add the optional signaling of the maximum=20 > > > content size you=20 > > > > are planning to _send_ into the SDP exchange. > > > >=20 > > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > > session, or one=20 > > > > value per each type for which we have indicated support. > > > >=20 > > > > My personal opinions: > > > >=20 > > > > No and No. In all honesty, I think this could be a useful=20 > > > feature, but I=20 > > > > don't think MSRP has to have it to function. I am voting=20 > > > no, not because=20 > > > > I disagree with the feature, but because I don't want to=20 > > > add additional=20 > > > > work to completing MSRP unless it is absolutely=20 > necessary. But if=20 > > > > consensus says we need it, I do not object on any=20 > technical basis. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Chris Boulton wrote: > > > >=20 > > > >> I think this feature would certainly be useful for max=20 > > > receive (if it=20 > > > >> was type specific) BUT I am not convinced about send. > > > >> =20 > > > >> Chris. > > > >> =20 > > > >> > > > >> -----Original Message----- From: Ben Campbell=20 > > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > > 25/05/2004 18:27=20 > > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > > hisham.khartabil@nokia.com;=20 > > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > > message size=20 > > > >> indication > > > >> =20 > > > >> =20 > > > >> > > > >> Let me step up a level: > > > >> =20 > > > >> By the required vs useful discussion, I was=20 > referring to the=20 > > > >> feature of > > > >> being able to signal size limitations itself, rather=20 > > than some=20 > > > >> aspect of > > > >> the feature. > > > >> =20 > > > >> So, what do others about whether the feature of being=20 > > > able to signal > > > >> message size limits is required? > > > >> =20 > > > >> Christer Holmberg (JO/LMF) wrote: > > > >> =20 > > > >> > Hi, > > > >> > > > > >> > > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > > blame the combined > > > >> >>ergonomics of Thunderbird and my laptop.) > > > >> >> > > > >> >>That brings up an interesting meta-question. What=20 > > is the bar > > > >> >>for putting new features into MSRP at this stage? Is=20 > > > "useful"=20 > > > >> enough? Or > > > >> >>should we limit new features to things that we=20 > decide are=20 > > > >> "required." > > > >> > > > > >> > > > > >> > Well, the max-receive is required, and I think=20 > it is very=20 > > > >> useful. As I wrote earlier, the question is if it should=20 > > > be possible=20 > > > >> to indicate separate values for different media types. > > > >> > > > > >> > The max-send is not required, but I still think it=20 > > > would be very=20 > > > >> useful. Earlier I gave some examples I think are very=20 > > > valid (nodes may=20 > > > >> try to reserve memory according to how much big messages=20 > > then can=20 > > > >> expect to receive, redirection/forking may be done=20 > based on the=20 > > > >> information etc etc etc). It wouldn't have any impacts on=20 > > > the protocol=20 > > > >> functionality itself, and there would be no interop=20 > > problems with=20 > > > >> nodes that don't understand the max-send=20 > > > attribute/parameter (or just=20 > > > >> don't care about it). > > > >> > > > > >> > Regards, > > > >> > > > > >> > Christer Holmberg > > > >> > Ericsson Finland > > > >> > > > > >> > > > > >> > > > > >> >>hisham.khartabil@nokia.com wrote: > > > >> >> > > > >> >> > > > >> >>>I think max-receive is useful, but not max-send. > > > >> >>> > > > >> >>>/Hisham > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>>>-----Original Message----- > > > >> >>>>From: simple-bounces@ietf.org > > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > >> >>>>Of ext Ben Campbell > > > >> >>>>Sent: 25.May.2004 17:49 > > > >> >>>>To: Christer Holmberg (JO/LMF) > > > >> >>>>Cc: 'simple@ietf.org' > > > >> >>>>Subject: [Simple] Re: MSRP: Max message size = indication > > > >> >>>> > > > >> >>>> > > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > > on the subject.) > > > >> >>>> > > > >> >>>>I do not have strong feelings on this as a=20 > > > requirement. If we > > > >> >>>>do want to > > > >> >>>>do it, the general approach seems good at the=20 > > first read,=20 > > > >> anyway. I > > > >> >>>>don't think there is a need for the non-type=20 > > specific size > > > >> >> > > > >> >>attribute. > > > >> >> > > > >> >>>>The only advantage would be to reduce size of=20 > the SDP. I > > > >> >>>>don't see that > > > >> >>>>as a big requirement, since it normally only=20 > happens one > > > >> >> > > > >> >>per session. > > > >> >> > > > >> >>>>Do others have thoughts on the matter? Do we need this > > > >> >> > > > >> >>feature at all? > > > >> >> > > > >> >>>> > > > >> >>>> > > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>>>Hi, > > > >> >>>>> > > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > > discussion I > > > >> >>>> > > > >> >>>>am bringing to the list the issue about being able to > > > >> >>>>indicate the max content size a node is able=20 > to receive. > > > >> >>>>Also, as input, in chapter 4 of > > > >> =20 > > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > >> >>>>a requirement for such functionality: > > > >> >>>> > > > >> >>>> > > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > the maximum > > > >> >>>> > > > >> >>>>message size it is willing to receive. > > > >> >>>> > > > >> >>>> > > > >> >>>>>I think it would be useful if clients could=20 > indicate the > > > >> >>>> > > > >> >>>>maximum payload size he is able to receive, and=20 > > also send, > > > >> >>>>either per type or stream. Note that I am=20 > > talking about the > > > >> >>>>total message/content size, not the size of individual > > > >> >>>>fragments (the spec does say that messages=20 > bigger than 2k > > > >> >>>>should be fragmented). > > > >> >>>> > > > >> >>>> > > > >> >>>>>If the max size is dependent on the media=20 > type, max size > > > >> >>>> > > > >> >>>>could be defined as a accept-type token paramter: > > > >> >>>> > > > >> >>>> > > > >> >>>>>example: > > > >> >>>>> > > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > > >> >>>> > > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > > >> >>>> > > > >> >>>> > > > >> >>>>>And, if the message size it not type dependent,=20 > > > generic max > > > >> >>>> > > > >> >>>>size attributes could be used. > > > >> >>>> > > > >> >>>> > > > >> >>>>>example: > > > >> >>>>> > > > >> >>>>>a=3Dmax-send: 1000 > > > >> >>>>>a=3Dmax-receive:1000 > > > >> >>>>> > > > >> >>>>>Even if one is not going to send more than the=20 > > other party > > > >> >>>> > > > >> >>>>indicates he is able to receive I still think it=20 > > > is important > > > >> >>>>that a node can indicate how much he is able=20 > to send. For > > > >> >>>>example, the remote node may reserve memory=20 > > > according to that > > > >> >>>>information, and/or intermediate proxies may do > > > >> >>>>forking/routing based on the client capabilities. > > > >> >>>> > > > >> >>>> > > > >> >>>>>An MSRP "message size too big" error code=20 > could also be > > > >> >>>> > > > >> >>>>useful, if a node for whatever reason is not able=20 > > > to accept a > > > >> >>>>SEND message. This may be due to that the=20 > remote node is > > > >> >>>>sending more data than was agreed in the=20 > > offer/answer, but > > > >> >>>>also due to that the receiving node for a short=20 > > > period isn't > > > >> >>>>able to receive the agreed data size (if the max=20 > > > size change > > > >> >>>>is permanent a new offer should of course be sent,=20 > > > instead of > > > >> >>>>sending an error reply to every SEND). At the=20 > > > interim meeting > > > >> >>>>is was desired to have a mechanism to "interrupt" the > > > >> >>>>receival of a message, and this error code could=20 > > be used to > > > >> >>>>indicate that. The sender would then stop sending the > > > >> >>>>message, and any possible yet unsent fragments. > > > >> >>>> > > > >> >>>> > > > >> >>>>>Regards, > > > >> >>>>> > > > >> >>>>>Christer Holmberg > > > >> >>>>>Ericsson Finland > > > >> >>>> > > > >> >>>> > > > >> >>>>_______________________________________________ > > > >> >>>>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 > > > >> > > > >> > > > >> > > > >> This message has been scanned for viruses by MailControl -=20 > > > >> www.mailcontrol.com > > > >> > > > >> > > > >> > > > >>=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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 05:26:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14110 for ; Tue, 8 Jun 2004 05:26:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXcsd-000255-U3 for simple-archive@ietf.org; Tue, 08 Jun 2004 05:26:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXcrH-0001JK-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 05:25:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXcpr-0000E6-00; Tue, 08 Jun 2004 05:23:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXcpt-00079j-5y; Tue, 08 Jun 2004 05:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXcms-0001AD-Vy; Tue, 08 Jun 2004 05:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXcgW-000811-IG for simple@megatron.ietf.org; Tue, 08 Jun 2004 05:14: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 FAA13541 for ; Tue, 8 Jun 2004 05:14:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXcgU-0001hr-4J for simple@ietf.org; Tue, 08 Jun 2004 05:14:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXcfe-000125-00 for simple@ietf.org; Tue, 08 Jun 2004 05:13:28 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BXcem-0000KP-00 for simple@ietf.org; Tue, 08 Jun 2004 05:12:32 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i589Bqx03877; Tue, 8 Jun 2004 12:11:52 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 12:11:47 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i589Blt5031544; Tue, 8 Jun 2004 12:11:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00n3c3Tn; Tue, 08 Jun 2004 12:11:45 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i589BiH24283; Tue, 8 Jun 2004 12:11:45 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 12:11:35 +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] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 12:11:35 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C02@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication thread-index: AcRNMHH+6nXL4cd5Sp6gITxEGorzgQABr5WQ To: , , X-OriginalArrivalTime: 08 Jun 2004 09:11:35.0368 (UTC) FILETIME=[9900A480:01C44D38] Content-Transfer-Encoding: quoted-printable Cc: cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Christer, Are you suggesting that SIP intermediaries examine the body of a SIP = message to make service/routing decisions? I see a problem here with = intermediaries examining SIP message bodies. What routing decision did = you have in mind? What services did you have in mind that require this = feature? Can you please present some explicit use cases? Also, if you are referring to MSRP intermediaries, then using SDP to = signal this does not help since there is no interface between MSRP = relays and the signalling network (that we will definitely not define). BTW, you have elevated the requirement from "the terminal cannot handle = such size messages" to "the network needs to do something". Which is you = requirement? Regards, Hisham > -----Original Message----- > From: ext Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 08.June.2004 11:09 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > bcampbell@dynamicsoft.com > Cc: cboulton@ubiquity.com; simple@ietf.org > Subject: RE: [Simple] Re: MSRP: Max message size indication >=20 >=20 >=20 > Hi Hisham, >=20 > >>The support and use of the attribute/parameter would be=20 > >>OPTIONAL, so if a node doesn't support the=20 > >>attribute/parameter (it is not able to calculate a value, it=20 > >>can't be configured, or the node simply thinks that size=20 > >>doesn't matter) everything will still work, as today, and it=20 > >>will then be "local policy" what to do if the messages can't=20 > >>be handled. > >=20 > >So, You send me an offer with receive-max-size of 1500 bytes,=20 > >but I don't understand that parameter. This doesn't help you.=20 > >I send you a message with 1Meg and you have to reject it with=20 > >a 4xx anyway. So where is the benefit of having this as optional? >=20 > The benefit is that you may have scenarios or network=20 > architectures where this information is used (not only by the=20 > end terminals, but also by intermediate nodes) for making=20 > service/routing/etc decissions. Of course, a node may always=20 > send too large messages, which have to be rejected (using a=20 > 4xx response), but the idea is to have a mechanism where this=20 > can be avoided. If big messages are to be sent I think it is=20 > very useful to have this information, in order to adjust=20 > terminal settings, and to make the transmission smooth, and=20 > in order to send lots of stuff on the network that may be=20 > rejected (that data may then have to be retransmitted, using=20 > smaller messages, or the session may fail). >=20 > This is similar to any other SDP attribute. If you don't=20 > support it, you discard it, and things should work anyway -=20 > but IF you support it it may provide you with useful=20 > information for optimal performance. >=20 > However, IF people prefear making support mandatory, I=20 > personally don't have anything against that. But, that's not=20 > what I am proposing, because I do realize there may be=20 > scenarios where this kind of information is not needed.=20 > Another option is making it mandatory, and defining a default=20 > value if the information is not present (similar to the=20 > "sendrecv" media direction attribute), but that is not what I=20 > am proposing either. My issue is that I think it's useful to=20 > have this kind of information. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 > >=20 > > /Hisham > >=20 > > >=20 > > > Of course, a node can send a 4xx response if the message it=20 > > > receives is too big, but as I said before, there may be=20 > > > scenarios where the size information is used to make=20 > > > decissions already at the session setup phase. > > >=20 > > > As Andrew said, this feature is especially useful for mobile=20 > > > devices, or other nodes with limited memory. > > >=20 > > > And, since there is a requirement at least for the receiving=20 > > > part, I assume it at some stage has been realized that the=20 > > > information could be useful. > > >=20 > > > Regards, > > >=20 > > > Christer Holmberg > > > Ericsson Finland > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: 7. kes=E4kuuta 2004 19:55 > > > > To: Ben Campbell > > > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > > > simple@ietf.org; Christer > > > > Holmberg (JO/LMF) > > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > >=20 > > > >=20 > > > > Ben, > > > >=20 > > > >=20 > > > > Paul > > > >=20 > > > > Ben Campbell wrote: > > > > > I'd like to try and get some closure on this: > > > > >=20 > > > > > Please answer yes or no to the following: > > > > >=20 > > > > > 1) Should we add the optional signaling of the maximum=20 > > > > content size you=20 > > > > > are willing to _receive_ into the SDP exchange. > > > > >=20 > > > > > 2) Should we add the optional signaling of the maximum=20 > > > > content size you=20 > > > > > are planning to _send_ into the SDP exchange. > > > > >=20 > > > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > > > session, or one=20 > > > > > value per each type for which we have indicated support. > > > > >=20 > > > > > My personal opinions: > > > > >=20 > > > > > No and No. In all honesty, I think this could be a useful=20 > > > > feature, but I=20 > > > > > don't think MSRP has to have it to function. I am voting=20 > > > > no, not because=20 > > > > > I disagree with the feature, but because I don't want to=20 > > > > add additional=20 > > > > > work to completing MSRP unless it is absolutely=20 > > necessary. But if=20 > > > > > consensus says we need it, I do not object on any=20 > > technical basis. > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Chris Boulton wrote: > > > > >=20 > > > > >> I think this feature would certainly be useful for max=20 > > > > receive (if it=20 > > > > >> was type specific) BUT I am not convinced about send. > > > > >> =20 > > > > >> Chris. > > > > >> =20 > > > > >> > > > > >> -----Original Message----- From: Ben Campbell=20 > > > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > > > 25/05/2004 18:27=20 > > > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > > > hisham.khartabil@nokia.com;=20 > > > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > > > message size=20 > > > > >> indication > > > > >> =20 > > > > >> =20 > > > > >> > > > > >> Let me step up a level: > > > > >> =20 > > > > >> By the required vs useful discussion, I was=20 > > referring to the=20 > > > > >> feature of > > > > >> being able to signal size limitations itself, rather=20 > > > than some=20 > > > > >> aspect of > > > > >> the feature. > > > > >> =20 > > > > >> So, what do others about whether the feature of being=20 > > > > able to signal > > > > >> message size limits is required? > > > > >> =20 > > > > >> Christer Holmberg (JO/LMF) wrote: > > > > >> =20 > > > > >> > Hi, > > > > >> > > > > > >> > > > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > > > blame the combined > > > > >> >>ergonomics of Thunderbird and my laptop.) > > > > >> >> > > > > >> >>That brings up an interesting meta-question. What=20 > > > is the bar > > > > >> >>for putting new features into MSRP at this stage? Is=20 > > > > "useful"=20 > > > > >> enough? Or > > > > >> >>should we limit new features to things that we=20 > > decide are=20 > > > > >> "required." > > > > >> > > > > > >> > > > > > >> > Well, the max-receive is required, and I think=20 > > it is very=20 > > > > >> useful. As I wrote earlier, the question is if it should=20 > > > > be possible=20 > > > > >> to indicate separate values for different media types. > > > > >> > > > > > >> > The max-send is not required, but I still think it=20 > > > > would be very=20 > > > > >> useful. Earlier I gave some examples I think are very=20 > > > > valid (nodes may=20 > > > > >> try to reserve memory according to how much big messages=20 > > > then can=20 > > > > >> expect to receive, redirection/forking may be done=20 > > based on the=20 > > > > >> information etc etc etc). It wouldn't have any impacts on=20 > > > > the protocol=20 > > > > >> functionality itself, and there would be no interop=20 > > > problems with=20 > > > > >> nodes that don't understand the max-send=20 > > > > attribute/parameter (or just=20 > > > > >> don't care about it). > > > > >> > > > > > >> > Regards, > > > > >> > > > > > >> > Christer Holmberg > > > > >> > Ericsson Finland > > > > >> > > > > > >> > > > > > >> > > > > > >> >>hisham.khartabil@nokia.com wrote: > > > > >> >> > > > > >> >> > > > > >> >>>I think max-receive is useful, but not max-send. > > > > >> >>> > > > > >> >>>/Hisham > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > >> >>>>-----Original Message----- > > > > >> >>>>From: simple-bounces@ietf.org > > > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > > >> >>>>Of ext Ben Campbell > > > > >> >>>>Sent: 25.May.2004 17:49 > > > > >> >>>>To: Christer Holmberg (JO/LMF) > > > > >> >>>>Cc: 'simple@ietf.org' > > > > >> >>>>Subject: [Simple] Re: MSRP: Max message size=20 > indication > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > > > on the subject.) > > > > >> >>>> > > > > >> >>>>I do not have strong feelings on this as a=20 > > > > requirement. If we > > > > >> >>>>do want to > > > > >> >>>>do it, the general approach seems good at the=20 > > > first read,=20 > > > > >> anyway. I > > > > >> >>>>don't think there is a need for the non-type=20 > > > specific size > > > > >> >> > > > > >> >>attribute. > > > > >> >> > > > > >> >>>>The only advantage would be to reduce size of=20 > > the SDP. I > > > > >> >>>>don't see that > > > > >> >>>>as a big requirement, since it normally only=20 > > happens one > > > > >> >> > > > > >> >>per session. > > > > >> >> > > > > >> >>>>Do others have thoughts on the matter? Do we=20 > need this > > > > >> >> > > > > >> >>feature at all? > > > > >> >> > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > > > >> >>>> > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>Hi, > > > > >> >>>>> > > > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > > > discussion I > > > > >> >>>> > > > > >> >>>>am bringing to the list the issue about being able to > > > > >> >>>>indicate the max content size a node is able=20 > > to receive. > > > > >> >>>>Also, as input, in chapter 4 of > > > > >> =20 > > > >=20 > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > > >> >>>>a requirement for such functionality: > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > > the maximum > > > > >> >>>> > > > > >> >>>>message size it is willing to receive. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>I think it would be useful if clients could=20 > > indicate the > > > > >> >>>> > > > > >> >>>>maximum payload size he is able to receive, and=20 > > > also send, > > > > >> >>>>either per type or stream. Note that I am=20 > > > talking about the > > > > >> >>>>total message/content size, not the size of=20 > individual > > > > >> >>>>fragments (the spec does say that messages=20 > > bigger than 2k > > > > >> >>>>should be fragmented). > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>If the max size is dependent on the media=20 > > type, max size > > > > >> >>>> > > > > >> >>>>could be defined as a accept-type token paramter: > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>example: > > > > >> >>>>> > > > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > > > >> >>>> > > > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>And, if the message size it not type dependent,=20 > > > > generic max > > > > >> >>>> > > > > >> >>>>size attributes could be used. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>example: > > > > >> >>>>> > > > > >> >>>>>a=3Dmax-send: 1000 > > > > >> >>>>>a=3Dmax-receive:1000 > > > > >> >>>>> > > > > >> >>>>>Even if one is not going to send more than the=20 > > > other party > > > > >> >>>> > > > > >> >>>>indicates he is able to receive I still think it=20 > > > > is important > > > > >> >>>>that a node can indicate how much he is able=20 > > to send. For > > > > >> >>>>example, the remote node may reserve memory=20 > > > > according to that > > > > >> >>>>information, and/or intermediate proxies may do > > > > >> >>>>forking/routing based on the client capabilities. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>An MSRP "message size too big" error code=20 > > could also be > > > > >> >>>> > > > > >> >>>>useful, if a node for whatever reason is not able=20 > > > > to accept a > > > > >> >>>>SEND message. This may be due to that the=20 > > remote node is > > > > >> >>>>sending more data than was agreed in the=20 > > > offer/answer, but > > > > >> >>>>also due to that the receiving node for a short=20 > > > > period isn't > > > > >> >>>>able to receive the agreed data size (if the max=20 > > > > size change > > > > >> >>>>is permanent a new offer should of course be sent,=20 > > > > instead of > > > > >> >>>>sending an error reply to every SEND). At the=20 > > > > interim meeting > > > > >> >>>>is was desired to have a mechanism to "interrupt" the > > > > >> >>>>receival of a message, and this error code could=20 > > > be used to > > > > >> >>>>indicate that. The sender would then stop sending the > > > > >> >>>>message, and any possible yet unsent fragments. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>Regards, > > > > >> >>>>> > > > > >> >>>>>Christer Holmberg > > > > >> >>>>>Ericsson Finland > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>_______________________________________________ > > > > >> >>>>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 > > > > >> > > > > >> > > > > >> > > > > >> This message has been scanned for viruses by MailControl -=20 > > > > >> www.mailcontrol.com > > > > >> > > > > >> > > > > >> > > > > >>=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 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 07:24:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19091 for ; Tue, 8 Jun 2004 07:24:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeiK-0005VC-Oi for simple-archive@ietf.org; Tue, 08 Jun 2004 07:24:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXehU-0004nf-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 07:23:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXegR-0003Qm-00; Tue, 08 Jun 2004 07:22:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeYn-0001C6-Bh; Tue, 08 Jun 2004 07:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeQ1-0007P0-6v for simple@megatron.ietf.org; Tue, 08 Jun 2004 07:05: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 HAA18161 for ; Tue, 8 Jun 2004 07:05:24 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXePy-0007kJ-HU for simple@ietf.org; Tue, 08 Jun 2004 07:05:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeOz-00073h-00 for simple@ietf.org; Tue, 08 Jun 2004 07:04:22 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BXeOH-0006NM-00 for simple@ietf.org; Tue, 08 Jun 2004 07:03:37 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B3bJ24030 for ; Tue, 8 Jun 2004 14:03:37 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 14:03:29 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i58B3TEb027377 for ; Tue, 8 Jun 2004 14:03:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 009yjDpE; Tue, 08 Jun 2004 14:03:28 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B3SH26659 for ; Tue, 8 Jun 2004 14:03:28 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 14:03:14 +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] Event Filtering Issue 1: Multiple filters for a resource Date: Tue, 8 Jun 2004 14:03:14 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C0A@esebe019.ntc.nokia.com> Thread-Topic: Event Filtering Issue 1: Multiple filters for a resource thread-index: AcRG/gRgny3FEin7SVaiMuQLndn9fAGSgZ/A To: X-OriginalArrivalTime: 08 Jun 2004 11:03:14.0440 (UTC) FILETIME=[31F5E880:01C44D48] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable A week has passed without comments on this issue. Therefore I conclude = that the proposal agreed on at the interim is acceptable. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 31.May.2004 13:57 > To: simple@ietf.org > Subject: [Simple] Event Filtering Issue 1: Multiple filters for a > resource >=20 >=20 > A SUBSCRIBE request is allowed to carry multiple filters (eg:=20 > If the subscribe is for a list). The problem when multiple=20 > filters are destined to the same resource. >=20 > SUBSCRIBE sip:myfirends@domain.com SIP/2.0 > ... > > xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf"> > > > =20 > //pidf:tuple/pidf:status/pidf:basic > > > > > type=3D"namespace">urn:ietf:params:xml:ns:pidf > //pidf:tuple/pidf:note > > > >=20 > We agreed at the interim that we need to add text that=20 > disallows more than 1 filter per resource to be specified. >=20 > Any objections? >=20 > Regards, > Hisham >=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-bounces@ietf.org Tue Jun 8 07:27:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19245 for ; Tue, 8 Jun 2004 07:27:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXelR-0007gI-8U for simple-archive@ietf.org; Tue, 08 Jun 2004 07:27:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXekb-0006xS-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 07:26:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXejY-0005u8-00; Tue, 08 Jun 2004 07:25:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeYn-0001CF-Ru; Tue, 08 Jun 2004 07:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeR3-0007Y3-2K for simple@megatron.ietf.org; Tue, 08 Jun 2004 07:06: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 HAA18185 for ; Tue, 8 Jun 2004 07:06:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeR0-0000eQ-GM for simple@ietf.org; Tue, 08 Jun 2004 07:06:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXePy-0007kO-00 for simple@ietf.org; Tue, 08 Jun 2004 07:05:23 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BXePC-00073q-00 for simple@ietf.org; Tue, 08 Jun 2004 07:04:35 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B4ZJ25682 for ; Tue, 8 Jun 2004 14:04:35 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 14:04:26 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i58B4QYT004760 for ; Tue, 8 Jun 2004 14:04:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 009ZV3O1; Tue, 08 Jun 2004 14:04:24 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B4OH09589 for ; Tue, 8 Jun 2004 14:04:24 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 14:04:16 +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] Event Filtering Issue 3: Domain filter vs. resource filter Date: Tue, 8 Jun 2004 14:04:16 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C0B@esebe019.ntc.nokia.com> Thread-Topic: Event Filtering Issue 3: Domain filter vs. resource filter thread-index: AcRHDYcz595Vfrl9SbiDTp5vLoTazAGOsoyQ To: , X-OriginalArrivalTime: 08 Jun 2004 11:04:16.0648 (UTC) FILETIME=[570A1880:01C44D48] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable A week has passed without comments on this issue. Therefore I conclude = that the proposal agreed on at the interim is acceptable. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 31.May.2004 15:48 > To: simple@ietf.org > Subject: [Simple] Event Filtering Issue 3: Domain filter vs. resource > filter >=20 >=20 > Some situations may arise where a subscriber may want to=20 > create a filter for a domain where the subscription may be=20 > fanned out to, but override it with a filter to a specific resource. >=20 > In this following example, a filter is set for example.com=20 > and for bob@example.com that overrides the domain filter. >=20 > > xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf"> > > > =20 > //pidf:tuple/pidf:status/pidf:basic > > > > > type=3D"namespace">urn:ietf:params:xml:ns:pidf > //pidf:tuple/pidf:note > > > >=20 > There were no objections to this behaviour in the interim. If=20 > there aren't any objections on the mailing list, I will add=20 > some clarification text on this issue. >=20 > Regards, > Hisham >=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-bounces@ietf.org Tue Jun 8 07:29:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19379 for ; Tue, 8 Jun 2004 07:29:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXenZ-0001MJ-7N for simple-archive@ietf.org; Tue, 08 Jun 2004 07:29:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXemQ-0000b7-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 07:28:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXel1-0006x2-00; Tue, 08 Jun 2004 07:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeYo-0001CR-Km; Tue, 08 Jun 2004 07:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeRt-0007jV-QM for simple@megatron.ietf.org; Tue, 08 Jun 2004 07:07: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 HAA18239 for ; Tue, 8 Jun 2004 07:07:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeRr-0001Ly-8h for simple@ietf.org; Tue, 08 Jun 2004 07:07:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeQu-0000dh-00 for simple@ietf.org; Tue, 08 Jun 2004 07:06:21 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXePs-0007im-00 for simple@ietf.org; Tue, 08 Jun 2004 07:05:16 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B5HH15247 for ; Tue, 8 Jun 2004 14:05:17 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 14:04:58 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i58B4wub030602 for ; Tue, 8 Jun 2004 14:04:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 007MYLfg; Tue, 08 Jun 2004 14:04:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B4uH27830 for ; Tue, 8 Jun 2004 14:04:56 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 14:04:47 +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] Event Filtering Issue 4: Replacing a filter Date: Tue, 8 Jun 2004 14:04:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C0C@esebe019.ntc.nokia.com> Thread-Topic: Event Filtering Issue 4: Replacing a filter thread-index: AcRHDjGukWk5RXX9Tdenm1wisp3VPAGOjP4Q To: X-OriginalArrivalTime: 08 Jun 2004 11:04:47.0724 (UTC) FILETIME=[698FEAC0:01C44D48] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable A week has passed without comments on this issue. Therefore I conclude = that the proposal agreed on at the interim is acceptable. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 31.May.2004 15:53 > To: simple@ietf.org > Subject: [Simple] Event Filtering Issue 4: Replacing a filter >=20 >=20 > There are scenarios where a subscriber has created a filter=20 > in a subscription but wishes to replace that filter with=20 > another. There were 2 options presented at the interim with=20 > me proposing to adopt the 2nd as the solution. >=20 > Option 1: remove and add a filter in the same subscription >=20 > > xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf"> > > > > =20 > //pidf:tuple/pidf:status/pidf:basic > > > >=20 > Option 2: Allow a filter to be replaced re-using the same filter id >=20 > > xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf"> > > > =20 > //pidf:tuple/pidf:status/pidf:basic > > > >=20 > No one objected to option 2. If there aren't any objections=20 > on the mailing list, I will add some clarification text on this issue. >=20 > Regards, > Hisham >=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-bounces@ietf.org Tue Jun 8 07:32:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19577 for ; Tue, 8 Jun 2004 07:32:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeps-0002yi-TV for simple-archive@ietf.org; Tue, 08 Jun 2004 07:32:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeog-000283-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 07:30:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXenc-0001JA-00; Tue, 08 Jun 2004 07:29:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeZF-0001QC-Mm; Tue, 08 Jun 2004 07:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeUj-00004z-6T for simple@megatron.ietf.org; Tue, 08 Jun 2004 07:10: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 HAA18413 for ; Tue, 8 Jun 2004 07:10:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeUg-0003Q6-N3 for simple@ietf.org; Tue, 08 Jun 2004 07:10:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeTh-0002ja-00 for simple@ietf.org; Tue, 08 Jun 2004 07:09:14 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXeSh-0001xd-00 for simple@ietf.org; Tue, 08 Jun 2004 07:08:11 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B8CH18168 for ; Tue, 8 Jun 2004 14:08:12 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 14:08:03 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i58B83Kk006667 for ; Tue, 8 Jun 2004 14:08:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 005KRllt; Tue, 08 Jun 2004 14:08:01 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B81H29785 for ; Tue, 8 Jun 2004 14:08:01 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 14:07:28 +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] Event Filtering Issue 2: Propagating filters Date: Tue, 8 Jun 2004 14:07:28 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C0D@esebe019.ntc.nokia.com> Thread-Topic: Event Filtering Issue 2: Propagating filters thread-index: AcRG/hwkYK0Lh9H1RwqzgGu7ArRymwGSpoXA To: , X-OriginalArrivalTime: 08 Jun 2004 11:07:28.0546 (UTC) FILETIME=[C96B6820:01C44D48] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable A week has passed without comments on this issue. Therefore I conclude = that the proposal I made below is acceptable. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 31.May.2004 13:58 > To: simple@ietf.org > Subject: [Simple] Event Filtering Issue 2: Propagating filters >=20 >=20 > Current text: "If the URI indicated by the filter is for one=20 > resource who's URI is NOT one of the URIs that result from a=20 > lookup, by the RLS, on the Request-URI, the filter is=20 > propagated to all the fanned out subscriptions." >=20 > For example: I we have 2 lists, each located on its own RLS: >=20 > List1 (list1@example1.com) on RLS1 has: > =A0=A0=A0=A0 bob@example1.com > =A0=A0=A0 =A0 list2@example2.com=A0 > List2 on RLS2=A0has: > =A0=A0=A0=A0 alice@example2.com >=20 > (Note: list2 is a resource in list1) >=20 > RLS1 receives the following SUBSCRIBE request: > - The SUBSCRIBE is for list1 > - contains 2 filters: one for sarah@example1.com and the=20 > other for alice@example2.com >=20 > SUBSCRIBE sip:List1@example1.com SIP/2.0 > ... > > xmlns:pidf=3D"urn:ietf:params:xml:ns:pidf"> > > > type=3D"namespace">urn:ietf:params:xml:ns:pidf > //pidf:tuple/pidf:note > > > > > //pidf:tuple/pidf:status/pidf:basic > > > >=20 > RLS1 fans out subscriptions to resources on list1. The=20 > current text suggests that all filters are propagated to RLS2=20 > since both sarah@example1.com and alice@example2.com are not=20 > resources in list1@example1.com. >=20 > There was a suggestion that if a filter is destined to a=20 > resource that is part not part of the list and is outside the=20 > administrative domain of an RLS, then that filter is=20 > propagated. The rest are consumed. In our example, only the=20 > filter to alice@example2.com is propagated since example2.com=20 > is not under the administrative domain of RLS1. The filter to=20 > sarah@example1.com is consumed. >=20 > This causes problems since sarah@example1.com could have been=20 > part of list2. The subscriber knows this but RLS1 doesn't. >=20 > So, there were 3 proposals: >=20 > 1. propagate all the filters to URIs not on the list >=20 > 2. propagate only filters destined to URIs not on the list=20 > and are not part of the administrative domain of the RLS=20 > creating the fanned out subscriptions. >=20 > 3. State only that the subscriber makes an agreement with the=20 > RLS and do not specify how the RLS fulfils the agreement. >=20 > The 3rd proposal was brought up in the interim. I'm not sure=20 > if it is the best alternative. RLSs have to do something=20 > anyway and I think it is better to specify what that is. This=20 > will enhance interoperability and client expectations. >=20 > I propose 2 with the modification that an RLS must maintain=20 > those filters it consumed and must somehow apply them to=20 > notifications it received. >=20 > Regards, > Hisham >=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-bounces@ietf.org Tue Jun 8 07:32:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19703 for ; Tue, 8 Jun 2004 07:32:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeqh-0003h1-Tj for simple-archive@ietf.org; Tue, 08 Jun 2004 07:32:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXepS-0002qe-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 07:31:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXeo7-0001N1-00; Tue, 08 Jun 2004 07:30:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeZG-0001QL-2J; Tue, 08 Jun 2004 07:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeUm-000058-31 for simple@megatron.ietf.org; Tue, 08 Jun 2004 07:10: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 HAA18426 for ; Tue, 8 Jun 2004 07:10:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeUj-0003QQ-HT for simple@ietf.org; Tue, 08 Jun 2004 07:10:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeTt-0002kZ-00 for simple@ietf.org; Tue, 08 Jun 2004 07:09:25 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXeT2-000241-00 for simple@ietf.org; Tue, 08 Jun 2004 07:08:32 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B8WH18550 for ; Tue, 8 Jun 2004 14:08:32 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 14:08:30 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i58B8UH6017159 for ; Tue, 8 Jun 2004 14:08:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00GrNDgr; Tue, 08 Jun 2004 14:08:28 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58B8MH13312 for ; Tue, 8 Jun 2004 14:08:22 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 14:08:19 +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] Event Filtering Issue 5: XPATH usage Date: Tue, 8 Jun 2004 14:08:19 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C0E@esebe019.ntc.nokia.com> Thread-Topic: Event Filtering Issue 5: XPATH usage thread-index: AcRHD4tGCAy4mjg3S46EnfeHJVrDmAGOU5oA To: , X-OriginalArrivalTime: 08 Jun 2004 11:08:19.0726 (UTC) FILETIME=[E7ECDAE0:01C44D48] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable A week has passed without comments on this issue. Therefore I conclude = that the proposal I made below is acceptable. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 31.May.2004 16:03 > To: simple@ietf.org > Subject: [Simple] Event Filtering Issue 5: XPATH usage >=20 >=20 > This issue was not presented at the interim. I only thought=20 > of it afterwards. >=20 > The current event notification filtering solution uses XPATH=20 > expression to identify the elements that a subscriber wishes=20 > to be notified about changes to it and/or wishes for to be=20 > included in the notification. >=20 > The issue is very similar to an XCAP issue: What if the XPATH=20 > expression evaluates to more than one element at a certain=20 > step? We cannot mandate an XML schema with restrictions as is=20 > done for XCAP since a) it is too late, b) might not be desirable >=20 > My proposal are: >=20 > 1. the filter would apply to all the elements that are=20 > evaluated. I.e. If a filter evaluates to 2 elements, both are included >=20 > 2. the first match wins. >=20 > I prefer proposal 1, but welcome other ideas. >=20 > Thanks, > Hisham >=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-bounces@ietf.org Tue Jun 8 07:52:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20544 for ; Tue, 8 Jun 2004 07:52:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXf9R-0002E7-JV for simple-archive@ietf.org; Tue, 08 Jun 2004 07:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXf8Q-0001Ve-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 07:51:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXf77-00007h-00; Tue, 08 Jun 2004 07:49:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXexJ-0006vl-4W; Tue, 08 Jun 2004 07:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeu6-0006Fr-SS for simple@megatron.ietf.org; Tue, 08 Jun 2004 07:36: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 HAA19955 for ; Tue, 8 Jun 2004 07:36:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeu6-0006X4-Bz for simple@ietf.org; Tue, 08 Jun 2004 07:36:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXet8-0005nF-00 for simple@ietf.org; Tue, 08 Jun 2004 07:35:32 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BXes5-00054T-00 for simple@ietf.org; Tue, 08 Jun 2004 07:34:25 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58BYOPA017656 for ; Tue, 8 Jun 2004 13:34:24 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 13:34:24 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 13:34:23 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, bcampbell@dynamicsoft.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 13:34:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 08 Jun 2004 11:34:24.0123 (UTC) FILETIME=[8C60E4B0:01C44D4C] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.ericsson.se id i58BYOPA017656 Content-Transfer-Encoding: quoted-printable Cc: cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Hisham, >Are you suggesting that SIP intermediaries examine the body=20 >of a SIP message to make service/routing decisions? [CHH] I gave that as an example, yes. It depends on how people impelemnt = their intermediates, what information they use to do decissions etc. This= kind of information MAY be used for service/routing/whatever decissions. >I see a problem here with intermediaries examining SIP message=20 >bodies. What routing decision did you have in mind? What=20 >services did you have in mind that require this feature? Can=20 >you please present some explicit use cases? [CHH] I don't it's very strange if I have a proxy (OR an end-node) which = does eg routing (or other kind of) decisions based on body information (e= g media types, codecs, accept-type in the case of MSRP, etc etc etc suppo= rted), or other message information. However, the point was to give an ex= ample where this kind of information MAY be useful before the session has= been established. I have not said that an intermediate MUST use this inf= ormation. >Also, if you are referring to MSRP intermediaries, then using=20 >SDP to signal this does not help since there is no interface=20 >between MSRP relays and the signalling network (that we will=20 >definitely not define). [CHH] I was referring to SIP intermediates, for example forking proxies. = I appologise if I wasn't clear enough on that. >BTW, you have elevated the requirement from "the terminal=20 >cannot handle such size messages" to "the network needs to do=20 >something". Which is you requirement? [CHH] The only requirement, as far as I can remember, I have been referri= ng to is that a terminal shall be able to indicate the message size it is= able to receive. The rest have been examples and cases where I think thi= s kind of information could be useful.=20 What requirement have I put on the network? What I said was that if a ter= minal sends messages which are too big for the other to handle that will = cause unecessary traffic on the network, and therefor it could be useful = to have the size information already before anything is sent (and eg reje= cted by 4xx). Regards, Christer Holmberg Ericsson Finland >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 08.June.2004 11:09 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); pkyzivat@cisco.com; > > bcampbell@dynamicsoft.com > > Cc: cboulton@ubiquity.com; simple@ietf.org > > Subject: RE: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > >=20 > > Hi Hisham, > >=20 > > >>The support and use of the attribute/parameter would be=20 > > >>OPTIONAL, so if a node doesn't support the=20 > > >>attribute/parameter (it is not able to calculate a value, it=20 > > >>can't be configured, or the node simply thinks that size=20 > > >>doesn't matter) everything will still work, as today, and it=20 > > >>will then be "local policy" what to do if the messages can't=20 > > >>be handled. > > >=20 > > >So, You send me an offer with receive-max-size of 1500 bytes,=20 > > >but I don't understand that parameter. This doesn't help you.=20 > > >I send you a message with 1Meg and you have to reject it with=20 > > >a 4xx anyway. So where is the benefit of having this as optional? > >=20 > > The benefit is that you may have scenarios or network=20 > > architectures where this information is used (not only by the=20 > > end terminals, but also by intermediate nodes) for making=20 > > service/routing/etc decissions. Of course, a node may always=20 > > send too large messages, which have to be rejected (using a=20 > > 4xx response), but the idea is to have a mechanism where this=20 > > can be avoided. If big messages are to be sent I think it is=20 > > very useful to have this information, in order to adjust=20 > > terminal settings, and to make the transmission smooth, and=20 > > in order to send lots of stuff on the network that may be=20 > > rejected (that data may then have to be retransmitted, using=20 > > smaller messages, or the session may fail). > >=20 > > This is similar to any other SDP attribute. If you don't=20 > > support it, you discard it, and things should work anyway -=20 > > but IF you support it it may provide you with useful=20 > > information for optimal performance. > >=20 > > However, IF people prefear making support mandatory, I=20 > > personally don't have anything against that. But, that's not=20 > > what I am proposing, because I do realize there may be=20 > > scenarios where this kind of information is not needed.=20 > > Another option is making it mandatory, and defining a default=20 > > value if the information is not present (similar to the=20 > > "sendrecv" media direction attribute), but that is not what I=20 > > am proposing either. My issue is that I think it's useful to=20 > > have this kind of information. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > > >=20 > > > /Hisham > > >=20 > > > >=20 > > > > Of course, a node can send a 4xx response if the message it=20 > > > > receives is too big, but as I said before, there may be=20 > > > > scenarios where the size information is used to make=20 > > > > decissions already at the session setup phase. > > > >=20 > > > > As Andrew said, this feature is especially useful for mobile=20 > > > > devices, or other nodes with limited memory. > > > >=20 > > > > And, since there is a requirement at least for the receiving=20 > > > > part, I assume it at some stage has been realized that the=20 > > > > information could be useful. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer Holmberg > > > > Ericsson Finland > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > Sent: 7. kes=E4kuuta 2004 19:55 > > > > > To: Ben Campbell > > > > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > > > > simple@ietf.org; Christer > > > > > Holmberg (JO/LMF) > > > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > > >=20 > > > > >=20 > > > > > Ben, > > > > >=20 > > > > >=20 > > > > > Paul > > > > >=20 > > > > > Ben Campbell wrote: > > > > > > I'd like to try and get some closure on this: > > > > > >=20 > > > > > > Please answer yes or no to the following: > > > > > >=20 > > > > > > 1) Should we add the optional signaling of the maximum=20 > > > > > content size you=20 > > > > > > are willing to _receive_ into the SDP exchange. > > > > > >=20 > > > > > > 2) Should we add the optional signaling of the maximum=20 > > > > > content size you=20 > > > > > > are planning to _send_ into the SDP exchange. > > > > > >=20 > > > > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > > > > session, or one=20 > > > > > > value per each type for which we have indicated support. > > > > > >=20 > > > > > > My personal opinions: > > > > > >=20 > > > > > > No and No. In all honesty, I think this could be a useful=20 > > > > > feature, but I=20 > > > > > > don't think MSRP has to have it to function. I am voting=20 > > > > > no, not because=20 > > > > > > I disagree with the feature, but because I don't want to=20 > > > > > add additional=20 > > > > > > work to completing MSRP unless it is absolutely=20 > > > necessary. But if=20 > > > > > > consensus says we need it, I do not object on any=20 > > > technical basis. > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Chris Boulton wrote: > > > > > >=20 > > > > > >> I think this feature would certainly be useful for max=20 > > > > > receive (if it=20 > > > > > >> was type specific) BUT I am not convinced about send. > > > > > >> =20 > > > > > >> Chris. > > > > > >> =20 > > > > > >> > > > > > >> -----Original Message----- From: Ben Campbell=20 > > > > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > > > > 25/05/2004 18:27=20 > > > > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > > > > hisham.khartabil@nokia.com;=20 > > > > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > > > > message size=20 > > > > > >> indication > > > > > >> =20 > > > > > >> =20 > > > > > >> > > > > > >> Let me step up a level: > > > > > >> =20 > > > > > >> By the required vs useful discussion, I was=20 > > > referring to the=20 > > > > > >> feature of > > > > > >> being able to signal size limitations itself, rather=20 > > > > than some=20 > > > > > >> aspect of > > > > > >> the feature. > > > > > >> =20 > > > > > >> So, what do others about whether the feature of being=20 > > > > > able to signal > > > > > >> message size limits is required? > > > > > >> =20 > > > > > >> Christer Holmberg (JO/LMF) wrote: > > > > > >> =20 > > > > > >> > Hi, > > > > > >> > > > > > > >> > > > > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > > > > blame the combined > > > > > >> >>ergonomics of Thunderbird and my laptop.) > > > > > >> >> > > > > > >> >>That brings up an interesting meta-question. What=20 > > > > is the bar > > > > > >> >>for putting new features into MSRP at this stage? Is=20 > > > > > "useful"=20 > > > > > >> enough? Or > > > > > >> >>should we limit new features to things that we=20 > > > decide are=20 > > > > > >> "required." > > > > > >> > > > > > > >> > > > > > > >> > Well, the max-receive is required, and I think=20 > > > it is very=20 > > > > > >> useful. As I wrote earlier, the question is if it should=20 > > > > > be possible=20 > > > > > >> to indicate separate values for different media types. > > > > > >> > > > > > > >> > The max-send is not required, but I still think it=20 > > > > > would be very=20 > > > > > >> useful. Earlier I gave some examples I think are very=20 > > > > > valid (nodes may=20 > > > > > >> try to reserve memory according to how much big messages=20 > > > > then can=20 > > > > > >> expect to receive, redirection/forking may be done=20 > > > based on the=20 > > > > > >> information etc etc etc). It wouldn't have any impacts on=20 > > > > > the protocol=20 > > > > > >> functionality itself, and there would be no interop=20 > > > > problems with=20 > > > > > >> nodes that don't understand the max-send=20 > > > > > attribute/parameter (or just=20 > > > > > >> don't care about it). > > > > > >> > > > > > > >> > Regards, > > > > > >> > > > > > > >> > Christer Holmberg > > > > > >> > Ericsson Finland > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >>hisham.khartabil@nokia.com wrote: > > > > > >> >> > > > > > >> >> > > > > > >> >>>I think max-receive is useful, but not max-send. > > > > > >> >>> > > > > > >> >>>/Hisham > > > > > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > > >> >>>>-----Original Message----- > > > > > >> >>>>From: simple-bounces@ietf.org > > > > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > > > >> >>>>Of ext Ben Campbell > > > > > >> >>>>Sent: 25.May.2004 17:49 > > > > > >> >>>>To: Christer Holmberg (JO/LMF) > > > > > >> >>>>Cc: 'simple@ietf.org' > > > > > >> >>>>Subject: [Simple] Re: MSRP: Max message size=20 > > indication > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > > > > on the subject.) > > > > > >> >>>> > > > > > >> >>>>I do not have strong feelings on this as a=20 > > > > > requirement. If we > > > > > >> >>>>do want to > > > > > >> >>>>do it, the general approach seems good at the=20 > > > > first read,=20 > > > > > >> anyway. I > > > > > >> >>>>don't think there is a need for the non-type=20 > > > > specific size > > > > > >> >> > > > > > >> >>attribute. > > > > > >> >> > > > > > >> >>>>The only advantage would be to reduce size of=20 > > > the SDP. I > > > > > >> >>>>don't see that > > > > > >> >>>>as a big requirement, since it normally only=20 > > > happens one > > > > > >> >> > > > > > >> >>per session. > > > > > >> >> > > > > > >> >>>>Do others have thoughts on the matter? Do we=20 > > need this > > > > > >> >> > > > > > >> >>feature at all? > > > > > >> >> > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>Hi, > > > > > >> >>>>> > > > > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > > > > discussion I > > > > > >> >>>> > > > > > >> >>>>am bringing to the list the issue about=20 > being able to > > > > > >> >>>>indicate the max content size a node is able=20 > > > to receive. > > > > > >> >>>>Also, as input, in chapter 4 of > > > > > >> =20 > > > > >=20 > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > > > >> >>>>a requirement for such functionality: > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > > > the maximum > > > > > >> >>>> > > > > > >> >>>>message size it is willing to receive. > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>I think it would be useful if clients could=20 > > > indicate the > > > > > >> >>>> > > > > > >> >>>>maximum payload size he is able to receive, and=20 > > > > also send, > > > > > >> >>>>either per type or stream. Note that I am=20 > > > > talking about the > > > > > >> >>>>total message/content size, not the size of=20 > > individual > > > > > >> >>>>fragments (the spec does say that messages=20 > > > bigger than 2k > > > > > >> >>>>should be fragmented). > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>If the max size is dependent on the media=20 > > > type, max size > > > > > >> >>>> > > > > > >> >>>>could be defined as a accept-type token paramter: > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>example: > > > > > >> >>>>> > > > > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > > > > >> >>>> > > > > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>And, if the message size it not type dependent,=20 > > > > > generic max > > > > > >> >>>> > > > > > >> >>>>size attributes could be used. > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>example: > > > > > >> >>>>> > > > > > >> >>>>>a=3Dmax-send: 1000 > > > > > >> >>>>>a=3Dmax-receive:1000 > > > > > >> >>>>> > > > > > >> >>>>>Even if one is not going to send more than the=20 > > > > other party > > > > > >> >>>> > > > > > >> >>>>indicates he is able to receive I still think it=20 > > > > > is important > > > > > >> >>>>that a node can indicate how much he is able=20 > > > to send. For > > > > > >> >>>>example, the remote node may reserve memory=20 > > > > > according to that > > > > > >> >>>>information, and/or intermediate proxies may do > > > > > >> >>>>forking/routing based on the client capabilities. > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>An MSRP "message size too big" error code=20 > > > could also be > > > > > >> >>>> > > > > > >> >>>>useful, if a node for whatever reason is not able=20 > > > > > to accept a > > > > > >> >>>>SEND message. This may be due to that the=20 > > > remote node is > > > > > >> >>>>sending more data than was agreed in the=20 > > > > offer/answer, but > > > > > >> >>>>also due to that the receiving node for a short=20 > > > > > period isn't > > > > > >> >>>>able to receive the agreed data size (if the max=20 > > > > > size change > > > > > >> >>>>is permanent a new offer should of course be sent,=20 > > > > > instead of > > > > > >> >>>>sending an error reply to every SEND). At the=20 > > > > > interim meeting > > > > > >> >>>>is was desired to have a mechanism to=20 > "interrupt" the > > > > > >> >>>>receival of a message, and this error code could=20 > > > > be used to > > > > > >> >>>>indicate that. The sender would then stop=20 > sending the > > > > > >> >>>>message, and any possible yet unsent fragments. > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>>Regards, > > > > > >> >>>>> > > > > > >> >>>>>Christer Holmberg > > > > > >> >>>>>Ericsson Finland > > > > > >> >>>> > > > > > >> >>>> > > > > > >> >>>>_______________________________________________ > > > > > >> >>>>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 > > > > > >> > > > > > >> > > > > > >> > > > > > >> This message has been scanned for viruses by MailControl -=20 > > > > > >> www.mailcontrol.com > > > > > >> > > > > > >> > > > > > >> > > > > > >>=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 > > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 10:04:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27782 for ; Tue, 8 Jun 2004 10:04:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhDa-0006EW-UK for simple-archive@ietf.org; Tue, 08 Jun 2004 10:04:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhCd-0005Rn-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 10:03:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXhBd-0004dY-00; Tue, 08 Jun 2004 10:02:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXhBd-0005ld-H0; Tue, 08 Jun 2004 10:02:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXh61-0000U7-Rr; Tue, 08 Jun 2004 09:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXh2k-000836-Vl for simple@megatron.ietf.org; Tue, 08 Jun 2004 09:53: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 JAA26980 for ; Tue, 8 Jun 2004 09:53:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXh2j-0005SH-QQ for simple@ietf.org; Tue, 08 Jun 2004 09:53:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXh1i-0004h5-00 for simple@ietf.org; Tue, 08 Jun 2004 09:52:32 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BXh0g-0003CB-00 for simple@ietf.org; Tue, 08 Jun 2004 09:51:26 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58Doql04857 for ; Tue, 8 Jun 2004 08:50:52 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 14:50:50 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C414C64@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Christer Holmberg (JO/LMF)" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 14:50:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Arguing that it is optional does not mean it should go into an RFC with = issues attached. We have to solve all the issues even for optional = capabilities, and even with restrictions, to be be adopted, it must = still be useful. Our concern on this is that while a message receiver may know the = maximum size messages it can buffer, any message sender would require = an interaction with the use of the application to decide what that = maximum might be. In most, if not all message sessions, that sending = size might not be known until the time it is required to send a = message, and the overflow may possibly not be known until the sender = has started sending the message. Thus I see some need by the receiver of a message to abort a message = when the internal buffers get full. What happens then - we still need = to deal with this case even if a size is negotiated. My assumption is = that an application would do the best to render what it has, = accompanied by some meaningful notation. Further recovery would then = take place at the application layer, e.g. a reply message saying "send = your message again without the picture because it was too big for my = receiver to handle".=20 Now give that we have to do that anyway, do we gain any advantage in = the few cases where the future message size is known at session = establishment time. regards Keith > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com] > Sent: 07 June 2004 18:23 > To: 'Paul Kyzivat'; Ben Campbell > Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org > Subject: RE: [Simple] Re: MSRP: Max message size indication >=20 >=20 >=20 > Hi, >=20 > I disagree, and my answer is yes/yes. >=20 > >I'm inclined to agree with you (no/no). For many nodes this=20 > is simply=20 > >not a number that is easily decided. If anything, I imagine=20 > >it would be best to negotiate this. But that requires the=20 > sender to pick=20 > >a maximum send value, even though the sender probably has no=20 > particular limit.=20 > >This just seems like a rat hole best avoided for now. >=20 > The support and use of the attribute/parameter would be=20 > OPTIONAL, so if a node doesn't support the=20 > attribute/parameter (it is not able to calculate a value, it=20 > can't be configured, or the node simply thinks that size=20 > doesn't matter) everything will still work, as today, and it=20 > will then be "local policy" what to do if the messages can't=20 > be handled. >=20 > Of course, a node can send a 4xx response if the message it=20 > receives is too big, but as I said before, there may be=20 > scenarios where the size information is used to make=20 > decissions already at the session setup phase. >=20 > As Andrew said, this feature is especially useful for mobile=20 > devices, or other nodes with limited memory. >=20 > And, since there is a requirement at least for the receiving=20 > part, I assume it at some stage has been realized that the=20 > information could be useful. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 7. kes=E4kuuta 2004 19:55 > > To: Ben Campbell > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > simple@ietf.org; Christer > > Holmberg (JO/LMF) > > Subject: Re: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > > Ben, > >=20 > >=20 > > Paul > >=20 > > Ben Campbell wrote: > > > I'd like to try and get some closure on this: > > >=20 > > > Please answer yes or no to the following: > > >=20 > > > 1) Should we add the optional signaling of the maximum=20 > > content size you=20 > > > are willing to _receive_ into the SDP exchange. > > >=20 > > > 2) Should we add the optional signaling of the maximum=20 > > content size you=20 > > > are planning to _send_ into the SDP exchange. > > >=20 > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > session, or one=20 > > > value per each type for which we have indicated support. > > >=20 > > > My personal opinions: > > >=20 > > > No and No. In all honesty, I think this could be a useful=20 > > feature, but I=20 > > > don't think MSRP has to have it to function. I am voting=20 > > no, not because=20 > > > I disagree with the feature, but because I don't want to=20 > > add additional=20 > > > work to completing MSRP unless it is absolutely necessary. But if = > > > consensus says we need it, I do not object on any technical = basis. > > >=20 > > >=20 > > >=20 > > >=20 > > > Chris Boulton wrote: > > >=20 > > >> I think this feature would certainly be useful for max=20 > > receive (if it=20 > > >> was type specific) BUT I am not convinced about send. > > >> =20 > > >> Chris. > > >> =20 > > >> > > >> -----Original Message----- From: Ben Campbell=20 > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > 25/05/2004 18:27=20 > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > hisham.khartabil@nokia.com;=20 > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > message size=20 > > >> indication > > >> =20 > > >> =20 > > >> > > >> Let me step up a level: > > >> =20 > > >> By the required vs useful discussion, I was referring to the = > > >> feature of > > >> being able to signal size limitations itself, rather=20 > than some=20 > > >> aspect of > > >> the feature. > > >> =20 > > >> So, what do others about whether the feature of being=20 > > able to signal > > >> message size limits is required? > > >> =20 > > >> Christer Holmberg (JO/LMF) wrote: > > >> =20 > > >> > Hi, > > >> > > > >> > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > blame the combined > > >> >>ergonomics of Thunderbird and my laptop.) > > >> >> > > >> >>That brings up an interesting meta-question. What=20 > is the bar > > >> >>for putting new features into MSRP at this stage? Is=20 > > "useful"=20 > > >> enough? Or > > >> >>should we limit new features to things that we decide are=20 > > >> "required." > > >> > > > >> > > > >> > Well, the max-receive is required, and I think it is very=20 > > >> useful. As I wrote earlier, the question is if it should=20 > > be possible=20 > > >> to indicate separate values for different media types. > > >> > > > >> > The max-send is not required, but I still think it=20 > > would be very=20 > > >> useful. Earlier I gave some examples I think are very=20 > > valid (nodes may=20 > > >> try to reserve memory according to how much big messages=20 > then can=20 > > >> expect to receive, redirection/forking may be done based on the=20 > > >> information etc etc etc). It wouldn't have any impacts on=20 > > the protocol=20 > > >> functionality itself, and there would be no interop=20 > problems with=20 > > >> nodes that don't understand the max-send=20 > > attribute/parameter (or just=20 > > >> don't care about it). > > >> > > > >> > Regards, > > >> > > > >> > Christer Holmberg > > >> > Ericsson Finland > > >> > > > >> > > > >> > > > >> >>hisham.khartabil@nokia.com wrote: > > >> >> > > >> >> > > >> >>>I think max-receive is useful, but not max-send. > > >> >>> > > >> >>>/Hisham > > >> >>> > > >> >>> > > >> >>> > > >> >>>>-----Original Message----- > > >> >>>>From: simple-bounces@ietf.org > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > >> >>>>Of ext Ben Campbell > > >> >>>>Sent: 25.May.2004 17:49 > > >> >>>>To: Christer Holmberg (JO/LMF) > > >> >>>>Cc: 'simple@ietf.org' > > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > > >> >>>> > > >> >>>> > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > on the subject.) > > >> >>>> > > >> >>>>I do not have strong feelings on this as a=20 > > requirement. If we > > >> >>>>do want to > > >> >>>>do it, the general approach seems good at the=20 > first read,=20 > > >> anyway. I > > >> >>>>don't think there is a need for the non-type=20 > specific size > > >> >> > > >> >>attribute. > > >> >> > > >> >>>>The only advantage would be to reduce size of the SDP. I > > >> >>>>don't see that > > >> >>>>as a big requirement, since it normally only happens one > > >> >> > > >> >>per session. > > >> >> > > >> >>>>Do others have thoughts on the matter? Do we need this > > >> >> > > >> >>feature at all? > > >> >> > > >> >>>> > > >> >>>> > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>>>Hi, > > >> >>>>> > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > discussion I > > >> >>>> > > >> >>>>am bringing to the list the issue about being able to > > >> >>>>indicate the max content size a node is able to receive. > > >> >>>>Also, as input, in chapter 4 of > > >> =20 > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > >> >>>>a requirement for such functionality: > > >> >>>> > > >> >>>> > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the = maximum > > >> >>>> > > >> >>>>message size it is willing to receive. > > >> >>>> > > >> >>>> > > >> >>>>>I think it would be useful if clients could indicate = the > > >> >>>> > > >> >>>>maximum payload size he is able to receive, and=20 > also send, > > >> >>>>either per type or stream. Note that I am=20 > talking about the > > >> >>>>total message/content size, not the size of individual > > >> >>>>fragments (the spec does say that messages bigger than = 2k > > >> >>>>should be fragmented). > > >> >>>> > > >> >>>> > > >> >>>>>If the max size is dependent on the media type, max = size > > >> >>>> > > >> >>>>could be defined as a accept-type token paramter: > > >> >>>> > > >> >>>> > > >> >>>>>example: > > >> >>>>> > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > >> >>>> > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > >> >>>> > > >> >>>> > > >> >>>>>And, if the message size it not type dependent,=20 > > generic max > > >> >>>> > > >> >>>>size attributes could be used. > > >> >>>> > > >> >>>> > > >> >>>>>example: > > >> >>>>> > > >> >>>>>a=3Dmax-send: 1000 > > >> >>>>>a=3Dmax-receive:1000 > > >> >>>>> > > >> >>>>>Even if one is not going to send more than the=20 > other party > > >> >>>> > > >> >>>>indicates he is able to receive I still think it=20 > > is important > > >> >>>>that a node can indicate how much he is able to send. = For > > >> >>>>example, the remote node may reserve memory=20 > > according to that > > >> >>>>information, and/or intermediate proxies may do > > >> >>>>forking/routing based on the client capabilities. > > >> >>>> > > >> >>>> > > >> >>>>>An MSRP "message size too big" error code could also be > > >> >>>> > > >> >>>>useful, if a node for whatever reason is not able=20 > > to accept a > > >> >>>>SEND message. This may be due to that the remote node is > > >> >>>>sending more data than was agreed in the=20 > offer/answer, but > > >> >>>>also due to that the receiving node for a short=20 > > period isn't > > >> >>>>able to receive the agreed data size (if the max=20 > > size change > > >> >>>>is permanent a new offer should of course be sent,=20 > > instead of > > >> >>>>sending an error reply to every SEND). At the=20 > > interim meeting > > >> >>>>is was desired to have a mechanism to "interrupt" the > > >> >>>>receival of a message, and this error code could=20 > be used to > > >> >>>>indicate that. The sender would then stop sending the > > >> >>>>message, and any possible yet unsent fragments. > > >> >>>> > > >> >>>> > > >> >>>>>Regards, > > >> >>>>> > > >> >>>>>Christer Holmberg > > >> >>>>>Ericsson Finland > > >> >>>> > > >> >>>> > > >> >>>>_______________________________________________ > > >> >>>>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 > > >> > > >> > > >> > > >> This message has been scanned for viruses by MailControl -=20 > > >> www.mailcontrol.com > > >> > > >> > > >> > > >>=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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 10:52:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00766 for ; Tue, 8 Jun 2004 10:52:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhy2-0003Wp-JA for simple-archive@ietf.org; Tue, 08 Jun 2004 10:52:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhwn-0002l2-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 10:51:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXhvo-0001GX-00; Tue, 08 Jun 2004 10:50:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhtL-0000vQ-1V; Tue, 08 Jun 2004 10:47:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhkF-0007c6-8U for simple@megatron.ietf.org; Tue, 08 Jun 2004 10:38: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 KAA00436 for ; Tue, 8 Jun 2004 10:38:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhkE-0000fg-5y for simple@ietf.org; Tue, 08 Jun 2004 10:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhjE-0007gq-00 for simple@ietf.org; Tue, 08 Jun 2004 10:37:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BXhiB-0006n6-00 for simple@ietf.org; Tue, 08 Jun 2004 10:36:24 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58EaCd06978; Tue, 8 Jun 2004 17:36:12 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 17:36:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i58Ea4Sn004696; Tue, 8 Jun 2004 17:36:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00gTTlfb; Tue, 08 Jun 2004 17:36:04 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58Ea4H13287; Tue, 8 Jun 2004 17:36:04 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 17:36:03 +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] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 17:36:03 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C14@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication thread-index: AcRNYcpNqu7djLo0S6SIQO6SR311kgAAvH/g To: , X-OriginalArrivalTime: 08 Jun 2004 14:36:03.0942 (UTC) FILETIME=[ED2D4860:01C44D65] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Furthermore. If my terminal has 10Meg free memory and some logic decides = that my IM session application gets 10% of that (1 Meg), so I signal = max-receive-size of 1 Meg. In the mean time, I have downloaded a 9 Meg mpeg from some sight. My = quota for IMS session would now change to 100K. Do I resignal that = max-receive-size has changed? Also, after I have signalled that the max-receive-size is 1Meg, I = receive a 1 Meg message and I accept it (since it did not exceed the = 1Meg max size limit). Then I receive a second one of those 1 Meg = messages, do I accept? What does max-receive-size really mean? Max size of messages in total in = this session? Max size of 1 message? How can I ever possibly determine = the maximum message size I can receive is? In any case, rejecting a = message because of size needs to be supported. Too many questions, too little time -> I vote no/no (not as a chair) /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Drage, Keith (Keith) > Sent: 08.June.2004 16:51 > To: Christer Holmberg (JO/LMF) > Cc: simple@ietf.org > Subject: RE: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Arguing that it is optional does not mean it should go into=20 > an RFC with issues attached. We have to solve all the issues=20 > even for optional capabilities, and even with restrictions,=20 > to be be adopted, it must still be useful. >=20 > Our concern on this is that while a message receiver may know=20 > the maximum size messages it can buffer, any message sender=20 > would require an interaction with the use of the application=20 > to decide what that maximum might be. In most, if not all=20 > message sessions, that sending size might not be known until=20 > the time it is required to send a message, and the overflow=20 > may possibly not be known until the sender has started=20 > sending the message. >=20 > Thus I see some need by the receiver of a message to abort a=20 > message when the internal buffers get full. What happens then=20 > - we still need to deal with this case even if a size is=20 > negotiated. My assumption is that an application would do the=20 > best to render what it has, accompanied by some meaningful=20 > notation. Further recovery would then take place at the=20 > application layer, e.g. a reply message saying "send your=20 > message again without the picture because it was too big for=20 > my receiver to handle".=20 >=20 > Now give that we have to do that anyway, do we gain any=20 > advantage in the few cases where the future message size is=20 > known at session establishment time. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com] > > Sent: 07 June 2004 18:23 > > To: 'Paul Kyzivat'; Ben Campbell > > Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org > > Subject: RE: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > >=20 > > Hi, > >=20 > > I disagree, and my answer is yes/yes. > >=20 > > >I'm inclined to agree with you (no/no). For many nodes this=20 > > is simply=20 > > >not a number that is easily decided. If anything, I imagine=20 > > >it would be best to negotiate this. But that requires the=20 > > sender to pick=20 > > >a maximum send value, even though the sender probably has no=20 > > particular limit.=20 > > >This just seems like a rat hole best avoided for now. > >=20 > > The support and use of the attribute/parameter would be=20 > > OPTIONAL, so if a node doesn't support the=20 > > attribute/parameter (it is not able to calculate a value, it=20 > > can't be configured, or the node simply thinks that size=20 > > doesn't matter) everything will still work, as today, and it=20 > > will then be "local policy" what to do if the messages can't=20 > > be handled. > >=20 > > Of course, a node can send a 4xx response if the message it=20 > > receives is too big, but as I said before, there may be=20 > > scenarios where the size information is used to make=20 > > decissions already at the session setup phase. > >=20 > > As Andrew said, this feature is especially useful for mobile=20 > > devices, or other nodes with limited memory. > >=20 > > And, since there is a requirement at least for the receiving=20 > > part, I assume it at some stage has been realized that the=20 > > information could be useful. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 7. kes=E4kuuta 2004 19:55 > > > To: Ben Campbell > > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > > simple@ietf.org; Christer > > > Holmberg (JO/LMF) > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > >=20 > > >=20 > > > Ben, > > >=20 > > >=20 > > > Paul > > >=20 > > > Ben Campbell wrote: > > > > I'd like to try and get some closure on this: > > > >=20 > > > > Please answer yes or no to the following: > > > >=20 > > > > 1) Should we add the optional signaling of the maximum=20 > > > content size you=20 > > > > are willing to _receive_ into the SDP exchange. > > > >=20 > > > > 2) Should we add the optional signaling of the maximum=20 > > > content size you=20 > > > > are planning to _send_ into the SDP exchange. > > > >=20 > > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > > session, or one=20 > > > > value per each type for which we have indicated support. > > > >=20 > > > > My personal opinions: > > > >=20 > > > > No and No. In all honesty, I think this could be a useful=20 > > > feature, but I=20 > > > > don't think MSRP has to have it to function. I am voting=20 > > > no, not because=20 > > > > I disagree with the feature, but because I don't want to=20 > > > add additional=20 > > > > work to completing MSRP unless it is absolutely=20 > necessary. But if=20 > > > > consensus says we need it, I do not object on any=20 > technical basis. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Chris Boulton wrote: > > > >=20 > > > >> I think this feature would certainly be useful for max=20 > > > receive (if it=20 > > > >> was type specific) BUT I am not convinced about send. > > > >> =20 > > > >> Chris. > > > >> =20 > > > >> > > > >> -----Original Message----- From: Ben Campbell=20 > > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > > 25/05/2004 18:27=20 > > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > > hisham.khartabil@nokia.com;=20 > > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > > message size=20 > > > >> indication > > > >> =20 > > > >> =20 > > > >> > > > >> Let me step up a level: > > > >> =20 > > > >> By the required vs useful discussion, I was=20 > referring to the=20 > > > >> feature of > > > >> being able to signal size limitations itself, rather=20 > > than some=20 > > > >> aspect of > > > >> the feature. > > > >> =20 > > > >> So, what do others about whether the feature of being=20 > > > able to signal > > > >> message size limits is required? > > > >> =20 > > > >> Christer Holmberg (JO/LMF) wrote: > > > >> =20 > > > >> > Hi, > > > >> > > > > >> > > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > > blame the combined > > > >> >>ergonomics of Thunderbird and my laptop.) > > > >> >> > > > >> >>That brings up an interesting meta-question. What=20 > > is the bar > > > >> >>for putting new features into MSRP at this stage? Is=20 > > > "useful"=20 > > > >> enough? Or > > > >> >>should we limit new features to things that we=20 > decide are=20 > > > >> "required." > > > >> > > > > >> > > > > >> > Well, the max-receive is required, and I think=20 > it is very=20 > > > >> useful. As I wrote earlier, the question is if it should=20 > > > be possible=20 > > > >> to indicate separate values for different media types. > > > >> > > > > >> > The max-send is not required, but I still think it=20 > > > would be very=20 > > > >> useful. Earlier I gave some examples I think are very=20 > > > valid (nodes may=20 > > > >> try to reserve memory according to how much big messages=20 > > then can=20 > > > >> expect to receive, redirection/forking may be done=20 > based on the=20 > > > >> information etc etc etc). It wouldn't have any impacts on=20 > > > the protocol=20 > > > >> functionality itself, and there would be no interop=20 > > problems with=20 > > > >> nodes that don't understand the max-send=20 > > > attribute/parameter (or just=20 > > > >> don't care about it). > > > >> > > > > >> > Regards, > > > >> > > > > >> > Christer Holmberg > > > >> > Ericsson Finland > > > >> > > > > >> > > > > >> > > > > >> >>hisham.khartabil@nokia.com wrote: > > > >> >> > > > >> >> > > > >> >>>I think max-receive is useful, but not max-send. > > > >> >>> > > > >> >>>/Hisham > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>>>-----Original Message----- > > > >> >>>>From: simple-bounces@ietf.org > > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > >> >>>>Of ext Ben Campbell > > > >> >>>>Sent: 25.May.2004 17:49 > > > >> >>>>To: Christer Holmberg (JO/LMF) > > > >> >>>>Cc: 'simple@ietf.org' > > > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > > > >> >>>> > > > >> >>>> > > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > > on the subject.) > > > >> >>>> > > > >> >>>>I do not have strong feelings on this as a=20 > > > requirement. If we > > > >> >>>>do want to > > > >> >>>>do it, the general approach seems good at the=20 > > first read,=20 > > > >> anyway. I > > > >> >>>>don't think there is a need for the non-type=20 > > specific size > > > >> >> > > > >> >>attribute. > > > >> >> > > > >> >>>>The only advantage would be to reduce size of=20 > the SDP. I > > > >> >>>>don't see that > > > >> >>>>as a big requirement, since it normally only=20 > happens one > > > >> >> > > > >> >>per session. > > > >> >> > > > >> >>>>Do others have thoughts on the matter? Do we need this > > > >> >> > > > >> >>feature at all? > > > >> >> > > > >> >>>> > > > >> >>>> > > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>>>Hi, > > > >> >>>>> > > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > > discussion I > > > >> >>>> > > > >> >>>>am bringing to the list the issue about being able to > > > >> >>>>indicate the max content size a node is able=20 > to receive. > > > >> >>>>Also, as input, in chapter 4 of > > > >> =20 > > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > >> >>>>a requirement for such functionality: > > > >> >>>> > > > >> >>>> > > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > the maximum > > > >> >>>> > > > >> >>>>message size it is willing to receive. > > > >> >>>> > > > >> >>>> > > > >> >>>>>I think it would be useful if clients could=20 > indicate the > > > >> >>>> > > > >> >>>>maximum payload size he is able to receive, and=20 > > also send, > > > >> >>>>either per type or stream. Note that I am=20 > > talking about the > > > >> >>>>total message/content size, not the size of individual > > > >> >>>>fragments (the spec does say that messages=20 > bigger than 2k > > > >> >>>>should be fragmented). > > > >> >>>> > > > >> >>>> > > > >> >>>>>If the max size is dependent on the media=20 > type, max size > > > >> >>>> > > > >> >>>>could be defined as a accept-type token paramter: > > > >> >>>> > > > >> >>>> > > > >> >>>>>example: > > > >> >>>>> > > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > > >> >>>> > > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > > >> >>>> > > > >> >>>> > > > >> >>>>>And, if the message size it not type dependent,=20 > > > generic max > > > >> >>>> > > > >> >>>>size attributes could be used. > > > >> >>>> > > > >> >>>> > > > >> >>>>>example: > > > >> >>>>> > > > >> >>>>>a=3Dmax-send: 1000 > > > >> >>>>>a=3Dmax-receive:1000 > > > >> >>>>> > > > >> >>>>>Even if one is not going to send more than the=20 > > other party > > > >> >>>> > > > >> >>>>indicates he is able to receive I still think it=20 > > > is important > > > >> >>>>that a node can indicate how much he is able=20 > to send. For > > > >> >>>>example, the remote node may reserve memory=20 > > > according to that > > > >> >>>>information, and/or intermediate proxies may do > > > >> >>>>forking/routing based on the client capabilities. > > > >> >>>> > > > >> >>>> > > > >> >>>>>An MSRP "message size too big" error code=20 > could also be > > > >> >>>> > > > >> >>>>useful, if a node for whatever reason is not able=20 > > > to accept a > > > >> >>>>SEND message. This may be due to that the=20 > remote node is > > > >> >>>>sending more data than was agreed in the=20 > > offer/answer, but > > > >> >>>>also due to that the receiving node for a short=20 > > > period isn't > > > >> >>>>able to receive the agreed data size (if the max=20 > > > size change > > > >> >>>>is permanent a new offer should of course be sent,=20 > > > instead of > > > >> >>>>sending an error reply to every SEND). At the=20 > > > interim meeting > > > >> >>>>is was desired to have a mechanism to "interrupt" the > > > >> >>>>receival of a message, and this error code could=20 > > be used to > > > >> >>>>indicate that. The sender would then stop sending the > > > >> >>>>message, and any possible yet unsent fragments. > > > >> >>>> > > > >> >>>> > > > >> >>>>>Regards, > > > >> >>>>> > > > >> >>>>>Christer Holmberg > > > >> >>>>>Ericsson Finland > > > >> >>>> > > > >> >>>> > > > >> >>>>_______________________________________________ > > > >> >>>>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 > > > >> > > > >> > > > >> > > > >> This message has been scanned for viruses by MailControl -=20 > > > >> www.mailcontrol.com > > > >> > > > >> > > > >> > > > >>=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 > >=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-bounces@ietf.org Tue Jun 8 10:57:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00957 for ; Tue, 8 Jun 2004 10:57:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXi2g-0007N0-QG for simple-archive@ietf.org; Tue, 08 Jun 2004 10:57:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXi1d-0006aD-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 10:56:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXi0j-00054J-00; Tue, 08 Jun 2004 10:55:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhtu-00011c-4d; Tue, 08 Jun 2004 10:48:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhr0-0000Lw-SA for simple@megatron.ietf.org; Tue, 08 Jun 2004 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 KAA00600 for ; Tue, 8 Jun 2004 10:45:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhqz-0005zP-75 for simple@ietf.org; Tue, 08 Jun 2004 10:45:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhpz-0005Dx-00 for simple@ietf.org; Tue, 08 Jun 2004 10:44:29 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXhoe-0003is-00 for simple@ietf.org; Tue, 08 Jun 2004 10:43:04 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i58EfkLp025072; Tue, 8 Jun 2004 09:41:46 -0500 Message-ID: <40C5D022.2060806@dynamicsoft.com> Date: Tue, 08 Jun 2004 09:41:38 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] Re: MSRP: Max message size indication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i58EfkLp025072 Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, "'hisham.khartabil@nokia.com'" , cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I don't want to get too deep in this until we have results on the "vote"=20 (running neck and neck at the moment.) But to risk jumping into=20 mechanism, comments inline: Christer Holmberg (JO/LMF) wrote: > Hi Hisham, >=20 >=20 >>>The support and use of the attribute/parameter would be=20 >>>OPTIONAL, so if a node doesn't support the=20 >>>attribute/parameter (it is not able to calculate a value, it=20 >>>can't be configured, or the node simply thinks that size=20 >>>doesn't matter) everything will still work, as today, and it=20 >>>will then be "local policy" what to do if the messages can't=20 >>>be handled. >> >>So, You send me an offer with receive-max-size of 1500 bytes,=20 >>but I don't understand that parameter. This doesn't help you.=20 >>I send you a message with 1Meg and you have to reject it with=20 >>a 4xx anyway. So where is the benefit of having this as optional? >=20 >=20 > The benefit is that you may have scenarios or network architectures whe= re this information is used (not only by the end terminals, but also by i= ntermediate nodes) for making service/routing/etc decissions. Of course, = a node may always send too large messages, which have to be rejected (usi= ng a 4xx response), but the idea is to have a mechanism where this can be= avoided. If big messages are to be sent I think it is very useful to hav= e this information, in order to adjust terminal settings, and to make the= transmission smooth, and in order to send lots of stuff on the network t= hat may be rejected (that data may then have to be retransmitted, using s= maller messages, or the session may fail). If this is something we expect proxies to use for routing decisions, we=20 should consider doing it in the headers, rather than in the body. So, is=20 there anything in caller-prefs that will help here? > This is similar to any other SDP attribute. If you don't support it, yo= u discard it, and things should work anyway - but IF you support it it ma= y provide you with useful information for optimal performance. >=20 > However, IF people prefear making support mandatory, I personally don't= have anything against that. But, that's not what I am proposing, because= I do realize there may be scenarios where this kind of information is no= t needed. Another option is making it mandatory, and defining a default v= alue if the information is not present (similar to the "sendrecv" media d= irection attribute), but that is not what I am proposing either. My issue= is that I think it's useful to have this kind of information. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >>/Hisham >> >> >>>Of course, a node can send a 4xx response if the message it=20 >>>receives is too big, but as I said before, there may be=20 >>>scenarios where the size information is used to make=20 >>>decissions already at the session setup phase. >>> >>>As Andrew said, this feature is especially useful for mobile=20 >>>devices, or other nodes with limited memory. >>> >>>And, since there is a requirement at least for the receiving=20 >>>part, I assume it at some stage has been realized that the=20 >>>information could be useful. >>> >>>Regards, >>> >>>Christer Holmberg >>>Ericsson Finland >>> >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: 7. kes=E4kuuta 2004 19:55 >>>>To: Ben Campbell >>>>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 >>>>simple@ietf.org; Christer >>>>Holmberg (JO/LMF) >>>>Subject: Re: [Simple] Re: MSRP: Max message size indication >>>> >>>> >>>>Ben, >>>> >>>> >>>> Paul >>>> >>>>Ben Campbell wrote: >>>> >>>>>I'd like to try and get some closure on this: >>>>> >>>>>Please answer yes or no to the following: >>>>> >>>>>1) Should we add the optional signaling of the maximum=20 >>>> >>>>content size you=20 >>>> >>>>>are willing to _receive_ into the SDP exchange. >>>>> >>>>>2) Should we add the optional signaling of the maximum=20 >>>> >>>>content size you=20 >>>> >>>>>are planning to _send_ into the SDP exchange. >>>>> >>>>>3) If either 1 or 2 is yes, do we send one value for the=20 >>>> >>>>session, or one=20 >>>> >>>>>value per each type for which we have indicated support. >>>>> >>>>>My personal opinions: >>>>> >>>>>No and No. In all honesty, I think this could be a useful=20 >>>> >>>>feature, but I=20 >>>> >>>>>don't think MSRP has to have it to function. I am voting=20 >>>> >>>>no, not because=20 >>>> >>>>>I disagree with the feature, but because I don't want to=20 >>>> >>>>add additional=20 >>>> >>>>>work to completing MSRP unless it is absolutely=20 >> >>necessary. But if=20 >> >>>>>consensus says we need it, I do not object on any=20 >> >>technical basis. >> >>>>> >>>>> >>>>> >>>>>Chris Boulton wrote: >>>>> >>>>> >>>>>>I think this feature would certainly be useful for max=20 >>>> >>>>receive (if it=20 >>>> >>>>>>was type specific) BUT I am not convinced about send. >>>>>>=20 >>>>>>Chris. >>>>>>=20 >>>>>> >>>>>> -----Original Message----- From: Ben Campbell=20 >>>>>>[mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 >>> >>>25/05/2004 18:27=20 >>> >>>>>> To: Christer Holmberg (JO/LMF) Cc:=20 >>>> >>>>hisham.khartabil@nokia.com;=20 >>>> >>>>>>simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 >>>> >>>>message size=20 >>>> >>>>>>indication >>>>>> =20 >>>>>> =20 >>>>>> >>>>>> Let me step up a level: >>>>>> =20 >>>>>> By the required vs useful discussion, I was=20 >> >>referring to the=20 >> >>>>>>feature of >>>>>> being able to signal size limitations itself, rather=20 >>> >>>than some=20 >>> >>>>>>aspect of >>>>>> the feature. >>>>>> =20 >>>>>> So, what do others about whether the feature of being=20 >>>> >>>>able to signal >>>> >>>>>> message size limits is required? >>>>>> =20 >>>>>> Christer Holmberg (JO/LMF) wrote: >>>>>> =20 >>>>>> > Hi, >>>>>> > >>>>>> > >>>>>> >>(Ignore my yet-another-empty reply. This time I=20 >>>> >>>>blame the combined >>>> >>>>>> >>ergonomics of Thunderbird and my laptop.) >>>>>> >> >>>>>> >>That brings up an interesting meta-question. What=20 >>> >>>is the bar >>> >>>>>> >>for putting new features into MSRP at this stage? Is=20 >>>> >>>>"useful"=20 >>>> >>>>>>enough? Or >>>>>> >>should we limit new features to things that we=20 >> >>decide are=20 >> >>>>>>"required." >>>>>> > >>>>>> > >>>>>> > Well, the max-receive is required, and I think=20 >> >>it is very=20 >> >>>>>>useful. As I wrote earlier, the question is if it should=20 >>>> >>>>be possible=20 >>>> >>>>>>to indicate separate values for different media types. >>>>>> > >>>>>> > The max-send is not required, but I still think it=20 >>>> >>>>would be very=20 >>>> >>>>>>useful. Earlier I gave some examples I think are very=20 >>>> >>>>valid (nodes may=20 >>>> >>>>>>try to reserve memory according to how much big messages=20 >>> >>>then can=20 >>> >>>>>>expect to receive, redirection/forking may be done=20 >> >>based on the=20 >> >>>>>>information etc etc etc). It wouldn't have any impacts on=20 >>>> >>>>the protocol=20 >>>> >>>>>>functionality itself, and there would be no interop=20 >>> >>>problems with=20 >>> >>>>>>nodes that don't understand the max-send=20 >>>> >>>>attribute/parameter (or just=20 >>>> >>>>>>don't care about it). >>>>>> > >>>>>> > Regards, >>>>>> > >>>>>> > Christer Holmberg >>>>>> > Ericsson Finland >>>>>> > >>>>>> > >>>>>> > >>>>>> >>hisham.khartabil@nokia.com wrote: >>>>>> >> >>>>>> >> >>>>>> >>>I think max-receive is useful, but not max-send. >>>>>> >>> >>>>>> >>>/Hisham >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>>>-----Original Message----- >>>>>> >>>>From: simple-bounces@ietf.org >>>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>>> >>>>Of ext Ben Campbell >>>>>> >>>>Sent: 25.May.2004 17:49 >>>>>> >>>>To: Christer Holmberg (JO/LMF) >>>>>> >>>>Cc: 'simple@ietf.org' >>>>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>(Oops, itchy trigger finger--ignore my last mail=20 >>>> >>>>on the subject.) >>>> >>>>>> >>>> >>>>>> >>>>I do not have strong feelings on this as a=20 >>>> >>>>requirement. If we >>>> >>>>>> >>>>do want to >>>>>> >>>>do it, the general approach seems good at the=20 >>> >>>first read,=20 >>> >>>>>>anyway. I >>>>>> >>>>don't think there is a need for the non-type=20 >>> >>>specific size >>> >>>>>> >> >>>>>> >>attribute. >>>>>> >> >>>>>> >>>>The only advantage would be to reduce size of=20 >> >>the SDP. I >> >>>>>> >>>>don't see that >>>>>> >>>>as a big requirement, since it normally only=20 >> >>happens one >> >>>>>> >> >>>>>> >>per session. >>>>>> >> >>>>>> >>>>Do others have thoughts on the matter? Do we need this >>>>>> >> >>>>>> >>feature at all? >>>>>> >> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>Christer Holmberg (JO/LMF) wrote: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>Hi, >>>>>> >>>>> >>>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 >>> >>>discussion I >>> >>>>>> >>>> >>>>>> >>>>am bringing to the list the issue about being able to >>>>>> >>>>indicate the max content size a node is able=20 >> >>to receive. >> >>>>>> >>>>Also, as input, in chapter 4 of >>>>>> =20 >>>>>> >>>>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is >>>>>> >>>>>> >>>>a requirement for such functionality: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 >> >>the maximum >> >>>>>> >>>> >>>>>> >>>>message size it is willing to receive. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>I think it would be useful if clients could=20 >> >>indicate the >> >>>>>> >>>> >>>>>> >>>>maximum payload size he is able to receive, and=20 >>> >>>also send, >>> >>>>>> >>>>either per type or stream. Note that I am=20 >>> >>>talking about the >>> >>>>>> >>>>total message/content size, not the size of individual >>>>>> >>>>fragments (the spec does say that messages=20 >> >>bigger than 2k >> >>>>>> >>>>should be fragmented). >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>If the max size is dependent on the media=20 >> >>type, max size >> >>>>>> >>>> >>>>>> >>>>could be defined as a accept-type token paramter: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>example: >>>>>> >>>>> >>>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, >>>>>> >>>> >>>>>> >>>>Y;max-send=3D2000;max-receive=3D500 >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>And, if the message size it not type dependent,=20 >>>> >>>>generic max >>>> >>>>>> >>>> >>>>>> >>>>size attributes could be used. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>example: >>>>>> >>>>> >>>>>> >>>>>a=3Dmax-send: 1000 >>>>>> >>>>>a=3Dmax-receive:1000 >>>>>> >>>>> >>>>>> >>>>>Even if one is not going to send more than the=20 >>> >>>other party >>> >>>>>> >>>> >>>>>> >>>>indicates he is able to receive I still think it=20 >>>> >>>>is important >>>> >>>>>> >>>>that a node can indicate how much he is able=20 >> >>to send. For >> >>>>>> >>>>example, the remote node may reserve memory=20 >>>> >>>>according to that >>>> >>>>>> >>>>information, and/or intermediate proxies may do >>>>>> >>>>forking/routing based on the client capabilities. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>An MSRP "message size too big" error code=20 >> >>could also be >> >>>>>> >>>> >>>>>> >>>>useful, if a node for whatever reason is not able=20 >>>> >>>>to accept a >>>> >>>>>> >>>>SEND message. This may be due to that the=20 >> >>remote node is >> >>>>>> >>>>sending more data than was agreed in the=20 >>> >>>offer/answer, but >>> >>>>>> >>>>also due to that the receiving node for a short=20 >>>> >>>>period isn't >>>> >>>>>> >>>>able to receive the agreed data size (if the max=20 >>>> >>>>size change >>>> >>>>>> >>>>is permanent a new offer should of course be sent,=20 >>>> >>>>instead of >>>> >>>>>> >>>>sending an error reply to every SEND). At the=20 >>>> >>>>interim meeting >>>> >>>>>> >>>>is was desired to have a mechanism to "interrupt" the >>>>>> >>>>receival of a message, and this error code could=20 >>> >>>be used to >>> >>>>>> >>>>indicate that. The sender would then stop sending the >>>>>> >>>>message, and any possible yet unsent fragments. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>Regards, >>>>>> >>>>> >>>>>> >>>>>Christer Holmberg >>>>>> >>>>>Ericsson Finland >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>_______________________________________________ >>>>>> >>>>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 >>>>>> >>>>>> >>>>>> >>>>>>This message has been scanned for viruses by MailControl -=20 >>>>>>www.mailcontrol.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 >>>>> >>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 12:16:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05893 for ; Tue, 8 Jun 2004 12:16:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjHR-0003Va-FX for simple-archive@ietf.org; Tue, 08 Jun 2004 12:16:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjGH-0002dv-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 12:15:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXjEr-0000x9-00; Tue, 08 Jun 2004 12:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXiyd-0000cz-P3; Tue, 08 Jun 2004 11:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXinD-000640-PR for simple@megatron.ietf.org; Tue, 08 Jun 2004 11:45: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 LAA03521 for ; Tue, 8 Jun 2004 11:45:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXinC-0002pE-Ux for simple@ietf.org; Tue, 08 Jun 2004 11:45:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXimB-00020z-00 for simple@ietf.org; Tue, 08 Jun 2004 11:44:35 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXiky-0000PP-00; Tue, 08 Jun 2004 11:43:20 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i58Fh9bo019599; Tue, 8 Jun 2004 11:43:10 -0400 (EDT) Message-ID: <40C5DE72.5040302@dynamicsoft.com> Date: Tue, 08 Jun 2004 11:42:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schmidt Christian References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , simple@ietf.org, Tschofenig Hannes Subject: [Simple] Re: Xcap authorization rules - Multiple URIs in Identity X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Right now, the common policy schema only allows one URI per identity. However, I see no specific reason for this constraint, and believe it should allow multiple URIs. The condition matches as long as *any* of the URi that are listed match. Without this there is needless duplication of rules. Since this is a common policy issue, I'm cc-ing geopriv. Hannes - are you ok with this change? Also, note that the common policy doc needs to say that, when the element has multiple conditions (such as ), the rule matches only if ALL conditions match (i.e., its an AND at that level). Thanks, Jonathan R. Schmidt Christian wrote: > Hi Jonathan, > > a short question, concerning the actual Version of your draft: > Presence Authorization Rules: draft-ietf-simple-presence-rules-00 > > Is it possible to use more then one uri in the Identity Element (3.1.1)? > > Example: > > > user1@example.com > user2@example.com > > > > This could be very helpful, to increase efficiency (subscription or change of rules). > There would be no need for an external reference and the related problems. > > Is it possible to extend section 3.1.1 of your draft, to make clear, > that multiple uri's are allowed? > > > Best Regards, > > +++++++++++++++++++++++++++++++++++++ > + Christian Schmidt, Siemens AG + > + Phone +49 89 636-75192 + > + Fax +49 89 636-75165 + > + Mobile +49 178 7700363 + > + christian-schmidt@siemens.com + > + schmidt-augsburg@t-online.de + > +++++++++++++++++++++++++++++++++++++ > -- 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-bounces@ietf.org Tue Jun 8 13:16:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09401 for ; Tue, 8 Jun 2004 13:16:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkDM-0004s2-6x for simple-archive@ietf.org; Tue, 08 Jun 2004 13:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkAc-0002wb-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:13:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXk7l-0001m5-03; Tue, 08 Jun 2004 13:10:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXk1D-0002jV-Fp; Tue, 08 Jun 2004 13:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjrP-0003Fk-4v; Tue, 08 Jun 2004 12:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjYm-0004pk-56 for simple@megatron.ietf.org; Tue, 08 Jun 2004 12:34: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 MAA06745 for ; Tue, 8 Jun 2004 12:34:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjYl-0002kS-7A for simple@ietf.org; Tue, 08 Jun 2004 12:34:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjXZ-0001qx-00 for simple@ietf.org; Tue, 08 Jun 2004 12:33:35 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BXjWQ-0000dm-00 for simple@ietf.org; Tue, 08 Jun 2004 12:32:22 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58GW3J00531; Tue, 8 Jun 2004 19:32:03 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 19:31:52 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i58GVq1q023857; Tue, 8 Jun 2004 19:31:52 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Cq8zlq; Tue, 08 Jun 2004 19:31:50 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58GVoH23811; Tue, 8 Jun 2004 19:31:50 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 19:31:49 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 19:31:49 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.81.84 172.21.81.84 via HTTP with MS-WebStorage 6.0.6249 Received: from esdhcp09nok08184.ntc.nokia.com by esebe013.ntc.nokia.com; 08 Jun 2004 19:31:48 +0300 Subject: Re: [Simple] Re: MSRP: Max message size indication From: Aki Niemi To: ext Ben Campbell In-Reply-To: <40C489F9.1010706@dynamicsoft.com> References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> <40C489F9.1010706@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1086712308.6399.3551.camel@esdhcp09nok08184.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 08 Jun 2004 19:31:48 +0300 X-OriginalArrivalTime: 08 Jun 2004 16:31:49.0076 (UTC) FILETIME=[18CCA140:01C44D76] Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I'll have to vote for no/no. I don't think it solves the real problem, which is not having the sender/recipient ability to abort transfer mid-message. Cheers, Aki On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > I'd like to try and get some closure on this: > > Please answer yes or no to the following: > > 1) Should we add the optional signaling of the maximum content size you > are willing to _receive_ into the SDP exchange. > > 2) Should we add the optional signaling of the maximum content size you > are planning to _send_ into the SDP exchange. > > 3) If either 1 or 2 is yes, do we send one value for the session, or one > value per each type for which we have indicated support. > > My personal opinions: > > No and No. In all honesty, I think this could be a useful feature, but I > don't think MSRP has to have it to function. I am voting no, not because > I disagree with the feature, but because I don't want to add additional > work to completing MSRP unless it is absolutely necessary. But if > consensus says we need it, I do not object on any technical basis. > > > > > Chris Boulton wrote: > > > I think this feature would certainly be useful for max receive (if it was type specific) BUT I am not convinced about send. > > > > Chris. > > > > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Tue 25/05/2004 18:27 > > To: Christer Holmberg (JO/LMF) > > Cc: hisham.khartabil@nokia.com; simple@ietf.org > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > > > > > > Let me step up a level: > > > > By the required vs useful discussion, I was referring to the feature of > > being able to signal size limitations itself, rather than some aspect of > > the feature. > > > > So, what do others about whether the feature of being able to signal > > message size limits is required? > > > > Christer Holmberg (JO/LMF) wrote: > > > > > Hi, > > > > > > > > >>(Ignore my yet-another-empty reply. This time I blame the combined > > >>ergonomics of Thunderbird and my laptop.) > > >> > > >>That brings up an interesting meta-question. What is the bar > > >>for putting new features into MSRP at this stage? Is "useful" enough? Or > > >>should we limit new features to things that we decide are "required." > > > > > > > > > Well, the max-receive is required, and I think it is very useful. As I wrote earlier, the question is if it should be possible to indicate separate values for different media types. > > > > > > The max-send is not required, but I still think it would be very useful. Earlier I gave some examples I think are very valid (nodes may try to reserve memory according to how much big messages then can expect to receive, redirection/forking may be done based on the information etc etc etc). It wouldn't have any impacts on the protocol functionality itself, and there would be no interop problems with nodes that don't understand the max-send attribute/parameter (or just don't care about it). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > >>hisham.khartabil@nokia.com wrote: > > >> > > >> > > >>>I think max-receive is useful, but not max-send. > > >>> > > >>>/Hisham > > >>> > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: simple-bounces@ietf.org > > >>>>[mailto:simple-bounces@ietf.org]On Behalf > > >>>>Of ext Ben Campbell > > >>>>Sent: 25.May.2004 17:49 > > >>>>To: Christer Holmberg (JO/LMF) > > >>>>Cc: 'simple@ietf.org' > > >>>>Subject: [Simple] Re: MSRP: Max message size indication > > >>>> > > >>>> > > >>>>(Oops, itchy trigger finger--ignore my last mail on the subject.) > > >>>> > > >>>>I do not have strong feelings on this as a requirement. If we > > >>>>do want to > > >>>>do it, the general approach seems good at the first read, anyway. I > > >>>>don't think there is a need for the non-type specific size > > >> > > >>attribute. > > >> > > >>>>The only advantage would be to reduce size of the SDP. I > > >>>>don't see that > > >>>>as a big requirement, since it normally only happens one > > >> > > >>per session. > > >> > > >>>>Do others have thoughts on the matter? Do we need this > > >> > > >>feature at all? > > >> > > >>>> > > >>>> > > >>>>Christer Holmberg (JO/LMF) wrote: > > >>>> > > >>>> > > >>>> > > >>>>>Hi, > > >>>>> > > >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > > >>>> > > >>>>am bringing to the list the issue about being able to > > >>>>indicate the max content size a node is able to receive. > > >>>>Also, as input, in chapter 4 of > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > >>>>a requirement for such functionality: > > >>>> > > >>>> > > >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > > >>>> > > >>>>message size it is willing to receive. > > >>>> > > >>>> > > >>>>>I think it would be useful if clients could indicate the > > >>>> > > >>>>maximum payload size he is able to receive, and also send, > > >>>>either per type or stream. Note that I am talking about the > > >>>>total message/content size, not the size of individual > > >>>>fragments (the spec does say that messages bigger than 2k > > >>>>should be fragmented). > > >>>> > > >>>> > > >>>>>If the max size is dependent on the media type, max size > > >>>> > > >>>>could be defined as a accept-type token paramter: > > >>>> > > >>>> > > >>>>>example: > > >>>>> > > >>>>>accept-type: X;max-send=1000;max-receive=1000, > > >>>> > > >>>>Y;max-send=2000;max-receive=500 > > >>>> > > >>>> > > >>>>>And, if the message size it not type dependent, generic max > > >>>> > > >>>>size attributes could be used. > > >>>> > > >>>> > > >>>>>example: > > >>>>> > > >>>>>a=max-send: 1000 > > >>>>>a=max-receive:1000 > > >>>>> > > >>>>>Even if one is not going to send more than the other party > > >>>> > > >>>>indicates he is able to receive I still think it is important > > >>>>that a node can indicate how much he is able to send. For > > >>>>example, the remote node may reserve memory according to that > > >>>>information, and/or intermediate proxies may do > > >>>>forking/routing based on the client capabilities. > > >>>> > > >>>> > > >>>>>An MSRP "message size too big" error code could also be > > >>>> > > >>>>useful, if a node for whatever reason is not able to accept a > > >>>>SEND message. This may be due to that the remote node is > > >>>>sending more data than was agreed in the offer/answer, but > > >>>>also due to that the receiving node for a short period isn't > > >>>>able to receive the agreed data size (if the max size change > > >>>>is permanent a new offer should of course be sent, instead of > > >>>>sending an error reply to every SEND). At the interim meeting > > >>>>is was desired to have a mechanism to "interrupt" the > > >>>>receival of a message, and this error code could be used to > > >>>>indicate that. The sender would then stop sending the > > >>>>message, and any possible yet unsent fragments. > > >>>> > > >>>> > > >>>>>Regards, > > >>>>> > > >>>>>Christer Holmberg > > >>>>>Ericsson Finland > > >>>> > > >>>> > > >>>>_______________________________________________ > > >>>>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 > > > > > > > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 13:16:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09425 for ; Tue, 8 Jun 2004 13:16:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkDQ-0004ud-EH for simple-archive@ietf.org; Tue, 08 Jun 2004 13:16:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkAg-0002xN-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:13:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXk7m-0001l8-01; Tue, 08 Jun 2004 13:10:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXk0S-0002dE-Ah; Tue, 08 Jun 2004 13:03:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjpH-00023o-BG; Tue, 08 Jun 2004 12:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjVy-0003WW-7z for simple@megatron.ietf.org; Tue, 08 Jun 2004 12:31: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 MAA06674 for ; Tue, 8 Jun 2004 12:31:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjVx-0000Cs-7u for simple@ietf.org; Tue, 08 Jun 2004 12:31:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjV6-00079x-00 for simple@ietf.org; Tue, 08 Jun 2004 12:31:00 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXjTz-0006HS-00 for simple@ietf.org; Tue, 08 Jun 2004 12:29:51 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58GTZH06946; Tue, 8 Jun 2004 19:29:35 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 19:29:24 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i58GTONU017447; Tue, 8 Jun 2004 19:29:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00TA0NiL; Tue, 08 Jun 2004 19:29:22 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58GTLH21661; Tue, 8 Jun 2004 19:29:21 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 19:29:20 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.81.84 172.21.81.84 via HTTP with MS-WebStorage 6.0.6249 Received: from esdhcp09nok08184.ntc.nokia.com by esebe013.ntc.nokia.com; 08 Jun 2004 19:29:20 +0300 Subject: RE: [Simple] Re: MSRP: Max message size indication From: Aki Niemi To: ext Adam Roach In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1086712159.6399.3543.camel@esdhcp09nok08184.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 08 Jun 2004 19:29:20 +0300 X-OriginalArrivalTime: 08 Jun 2004 16:29:20.0833 (UTC) FILETIME=[C0708B10:01C44D75] Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, "'hisham.khartabil@nokia.com'" , Ben Campbell , christer.holmberg@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Mon, 2004-06-07 at 19:34, ext Adam Roach wrote: > Hisham Khartabil wrote: > > > Mandating chunking for messages larger than x bytes seems to > > enable receivers to send back a 4xx response telling the > > sender to stop. > > I'm not certain this is necessary, and I'm pretty sure > that it's not sufficient. > > For starters, we haven't yet said that you must wait for > the end of a message before you respond to it. I see > no reason that you couldn't send an error response to > a SEND transaction while it's still streaming at you. > The adjacent hop could then stop sending you the content > (that is, send the boundary with a "+" indicator at > the end -- or possibly, we could add a new "!" indicator > that means "aborted."). This could work. Of course it sort of stretches the concept of request-response, if it requires waiting for a response for a request that is still in the process of being sent. But this may not be such a big problem. I like the "!" indicator a lot. Actually, it is useful also in case the *sender* needs to abort mid-message. It avoids the recipient rendering content that is incomplete, possibly resulting in all sorts of weirdness and garbled content being displayed to the recipient. > The issue of squelching the message all the way back to > the sender (in the case of a session with relays) is > also slightly problematic, unless we do something like > mandate that negative DSNs are always on. I don't think > that all parties involved in this discussion would be > happy with such a decision. Well, I have a hard time seeing this protocol work unless there is always the possibility for end-to-end error responses. But this is probably just because I don't fully understand the requirement for optionality of the DSNs. In fact it doesn't make any sense to me. What application is happy to keep on sending a message when the recipient has already aborted it, and the relay is simply forwarding the stream to /dev/null? Examples, please. Cheers, Aki > /a > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 8 13:16:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09469 for ; Tue, 8 Jun 2004 13:16:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkDa-00052L-58 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:16:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkAr-0002zw-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:14:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXk7o-0001l8-00; Tue, 08 Jun 2004 13:11:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXjxo-0002I6-9I; Tue, 08 Jun 2004 13:00:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjir-0008IW-2Y; Tue, 08 Jun 2004 12:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjPv-0008P9-0z for simple@megatron.ietf.org; Tue, 08 Jun 2004 12:25: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 MAA06303 for ; Tue, 8 Jun 2004 12:25:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjPu-0002xW-0K for simple@ietf.org; Tue, 08 Jun 2004 12:25:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjOy-00029r-00 for simple@ietf.org; Tue, 08 Jun 2004 12:24:41 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BXjO1-0001LX-00; Tue, 08 Jun 2004 12:23:41 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i58GNdG12811; Tue, 8 Jun 2004 18:23:40 +0200 (MEST) Received: from hannes (cert-mchp1-35.esn.sbs.de [139.25.62.35]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i58GNcg02986; Tue, 8 Jun 2004 18:23:38 +0200 (MEST) Message-Id: <200406081623.i58GNcg02986@mail1.siemens.de> From: "Hannes Tschofenig" To: "'Jonathan Rosenberg'" , "'Schmidt Christian'" Date: Tue, 8 Jun 2004 18:23:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRNbzNDUkZGncHASQKQJegu1udQbQABYxTQ In-Reply-To: <40C5DE72.5040302@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, simple@ietf.org Subject: [Simple] RE: Xcap authorization rules - Multiple URIs in Identity X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi jonathan, > > Right now, the common policy schema only allows one URI per identity. > However, I see no specific reason for this constraint, and > believe it should allow multiple URIs. The condition matches > as long as *any* of the URi that are listed match. Without > this there is needless duplication of rules. i agree with you. > > Since this is a common policy issue, I'm cc-ing geopriv. > Hannes - are you ok with this change? fine with me. > > Also, note that the common policy doc needs to say that, when > the element has multiple conditions (such as > ), the rule matches only if ALL conditions match > (i.e., its an AND at that level). > that's correct. ciao hannes > Thanks, > Jonathan R. > > Schmidt Christian wrote: > > > Hi Jonathan, > > > > a short question, concerning the actual Version of your draft: > > Presence Authorization Rules: draft-ietf-simple-presence-rules-00 > > > > Is it possible to use more then one uri in the Identity Element > (3.1.1)? > > > > Example: > > > > > > user1@example.com > > user2@example.com > > > > > > > > This could be very helpful, to increase efficiency (subscription or > change of rules). > > There would be no need for an external reference and the related > problems. > > > > Is it possible to extend section 3.1.1 of your draft, to > make clear, > > that multiple uri's are allowed? > > > > > > Best Regards, > > > > +++++++++++++++++++++++++++++++++++++ > > + Christian Schmidt, Siemens AG + > > + Phone +49 89 636-75192 + > > + Fax +49 89 636-75165 + > > + Mobile +49 178 7700363 + > > + christian-schmidt@siemens.com + > > + schmidt-augsburg@t-online.de + > > +++++++++++++++++++++++++++++++++++++ > > > > -- > 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-bounces@ietf.org Tue Jun 8 13:48:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12420 for ; Tue, 8 Jun 2004 13:48:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkiW-0005hc-T2 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkhW-0004qN-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:47:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXkga-0003Ls-00; Tue, 08 Jun 2004 13:46:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkb6-0001le-UA; Tue, 08 Jun 2004 13:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkQp-0006jF-6q for simple@megatron.ietf.org; Tue, 08 Jun 2004 13:30: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 NAA10654 for ; Tue, 8 Jun 2004 13:30:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkQo-0000tb-2Y for simple@ietf.org; Tue, 08 Jun 2004 13:30:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkPq-000069-00 for simple@ietf.org; Tue, 08 Jun 2004 13:29:40 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BXkPK-00076N-00 for simple@ietf.org; Tue, 08 Jun 2004 13:29:06 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58HT5WR002425 for ; Tue, 8 Jun 2004 19:29:05 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 19:29:05 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 19:29:05 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Drage, Keith (Keith)'" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 19:28:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 08 Jun 2004 17:29:05.0686 (UTC) FILETIME=[192DB360:01C44D7E] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i58HT5WR002425 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Keith, Comments inline ([CHH]) >Arguing that it is optional does not mean it should go into=20 >an RFC with issues attached. We have to solve all the issues=20 >even for optional capabilities, and even with restrictions,=20 >to be be adopted, it must still be useful. [CHH] The proposal to make it optional was not be get around other issues= . Of course they have to be solved - no matter if we have a max size indi= cator or not. =20 >Our concern on this is that while a message receiver may know=20 >the maximum size messages it can buffer, any message sender=20 >would require an interaction with the use of the application=20 >to decide what that maximum might be. In most, if not all=20 >message sessions, that sending size might not be known until=20 >the time it is required to send a message, and the overflow=20 >may possibly not be known until the sender has started=20 >sending the message. [CHH] Of course, I am sure there are cases where there may be overflows, = and for that we need a way to reject a message which is already being sen= t. This we need no matter if we have a size indicator or not. However, if I do indicate a max size buffer to you, at least you have som= e value to use when you start sending me messages. Your issue about WHEN = a node really knows how much it can receive I think is an implementation = issue. =20 >Thus I see some need by the receiver of a message to abort a=20 >message when the internal buffers get full. >What happens then - we still need to deal with this case even if a size = is=20 >negotiated. [CHH] I totally agree. And, there has being discussions about sending a 4= xx response before the message has been received. >My assumption is that an application would do the best to render what it= has, accompanied by some meaningful=20 >notation. Further recovery would then take place at the application laye= r, e.g. a reply message saying "send your=20 >message again without the picture because it was too big for my receiver= to handle".=20 [CHH] Again, I agree. But, I still think many of these scenarios could be= avoided by indicating the max size already before the message is sent. A= nd, as I wrote in one of my initial posts, even if I have indicated that = I receive X bytes, there may be periodic occations when I am not, in whic= h case I may have to reject your message. But again, IF I at the session = setup know how much I will be able to receive, at least most of the time,= most of these overflow scenarios can be avoided.=20 And, if you don't know how much you will be able to receive, you don't in= dicate anything, and will then reject messages if too big. And, even if you don't know how much you will be able to receive, I can s= till indicate to you (using the max-SEND attribute) how much I will be ab= le send, which could be useful information for you. >Now give that we have to do that anyway, do we gain any=20 >advantage in the few cases where the future message size is=20 >known at session establishment time. [CHH] Well, it depends how "few" those cases are. Regards, Christer Holmberg Ericsson Finland >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com] > > Sent: 07 June 2004 18:23 > > To: 'Paul Kyzivat'; Ben Campbell > > Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org > > Subject: RE: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > >=20 > > Hi, > >=20 > > I disagree, and my answer is yes/yes. > >=20 > > >I'm inclined to agree with you (no/no). For many nodes this=20 > > is simply=20 > > >not a number that is easily decided. If anything, I imagine=20 > > >it would be best to negotiate this. But that requires the=20 > > sender to pick=20 > > >a maximum send value, even though the sender probably has no=20 > > particular limit.=20 > > >This just seems like a rat hole best avoided for now. > >=20 > > The support and use of the attribute/parameter would be=20 > > OPTIONAL, so if a node doesn't support the=20 > > attribute/parameter (it is not able to calculate a value, it=20 > > can't be configured, or the node simply thinks that size=20 > > doesn't matter) everything will still work, as today, and it=20 > > will then be "local policy" what to do if the messages can't=20 > > be handled. > >=20 > > Of course, a node can send a 4xx response if the message it=20 > > receives is too big, but as I said before, there may be=20 > > scenarios where the size information is used to make=20 > > decissions already at the session setup phase. > >=20 > > As Andrew said, this feature is especially useful for mobile=20 > > devices, or other nodes with limited memory. > >=20 > > And, since there is a requirement at least for the receiving=20 > > part, I assume it at some stage has been realized that the=20 > > information could be useful. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 7. kes=E4kuuta 2004 19:55 > > > To: Ben Campbell > > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > > simple@ietf.org; Christer > > > Holmberg (JO/LMF) > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > >=20 > > >=20 > > > Ben, > > >=20 > > >=20 > > > Paul > > >=20 > > > Ben Campbell wrote: > > > > I'd like to try and get some closure on this: > > > >=20 > > > > Please answer yes or no to the following: > > > >=20 > > > > 1) Should we add the optional signaling of the maximum=20 > > > content size you=20 > > > > are willing to _receive_ into the SDP exchange. > > > >=20 > > > > 2) Should we add the optional signaling of the maximum=20 > > > content size you=20 > > > > are planning to _send_ into the SDP exchange. > > > >=20 > > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > > session, or one=20 > > > > value per each type for which we have indicated support. > > > >=20 > > > > My personal opinions: > > > >=20 > > > > No and No. In all honesty, I think this could be a useful=20 > > > feature, but I=20 > > > > don't think MSRP has to have it to function. I am voting=20 > > > no, not because=20 > > > > I disagree with the feature, but because I don't want to=20 > > > add additional=20 > > > > work to completing MSRP unless it is absolutely=20 > necessary. But if=20 > > > > consensus says we need it, I do not object on any=20 > technical basis. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Chris Boulton wrote: > > > >=20 > > > >> I think this feature would certainly be useful for max=20 > > > receive (if it=20 > > > >> was type specific) BUT I am not convinced about send. > > > >> =20 > > > >> Chris. > > > >> =20 > > > >> > > > >> -----Original Message----- From: Ben Campbell=20 > > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > > 25/05/2004 18:27=20 > > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > > hisham.khartabil@nokia.com;=20 > > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > > message size=20 > > > >> indication > > > >> =20 > > > >> =20 > > > >> > > > >> Let me step up a level: > > > >> =20 > > > >> By the required vs useful discussion, I was=20 > referring to the=20 > > > >> feature of > > > >> being able to signal size limitations itself, rather=20 > > than some=20 > > > >> aspect of > > > >> the feature. > > > >> =20 > > > >> So, what do others about whether the feature of being=20 > > > able to signal > > > >> message size limits is required? > > > >> =20 > > > >> Christer Holmberg (JO/LMF) wrote: > > > >> =20 > > > >> > Hi, > > > >> > > > > >> > > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > > blame the combined > > > >> >>ergonomics of Thunderbird and my laptop.) > > > >> >> > > > >> >>That brings up an interesting meta-question. What=20 > > is the bar > > > >> >>for putting new features into MSRP at this stage? Is=20 > > > "useful"=20 > > > >> enough? Or > > > >> >>should we limit new features to things that we=20 > decide are=20 > > > >> "required." > > > >> > > > > >> > > > > >> > Well, the max-receive is required, and I think=20 > it is very=20 > > > >> useful. As I wrote earlier, the question is if it should=20 > > > be possible=20 > > > >> to indicate separate values for different media types. > > > >> > > > > >> > The max-send is not required, but I still think it=20 > > > would be very=20 > > > >> useful. Earlier I gave some examples I think are very=20 > > > valid (nodes may=20 > > > >> try to reserve memory according to how much big messages=20 > > then can=20 > > > >> expect to receive, redirection/forking may be done=20 > based on the=20 > > > >> information etc etc etc). It wouldn't have any impacts on=20 > > > the protocol=20 > > > >> functionality itself, and there would be no interop=20 > > problems with=20 > > > >> nodes that don't understand the max-send=20 > > > attribute/parameter (or just=20 > > > >> don't care about it). > > > >> > > > > >> > Regards, > > > >> > > > > >> > Christer Holmberg > > > >> > Ericsson Finland > > > >> > > > > >> > > > > >> > > > > >> >>hisham.khartabil@nokia.com wrote: > > > >> >> > > > >> >> > > > >> >>>I think max-receive is useful, but not max-send. > > > >> >>> > > > >> >>>/Hisham > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>>>-----Original Message----- > > > >> >>>>From: simple-bounces@ietf.org > > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > >> >>>>Of ext Ben Campbell > > > >> >>>>Sent: 25.May.2004 17:49 > > > >> >>>>To: Christer Holmberg (JO/LMF) > > > >> >>>>Cc: 'simple@ietf.org' > > > >> >>>>Subject: [Simple] Re: MSRP: Max message size indication > > > >> >>>> > > > >> >>>> > > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > > on the subject.) > > > >> >>>> > > > >> >>>>I do not have strong feelings on this as a=20 > > > requirement. If we > > > >> >>>>do want to > > > >> >>>>do it, the general approach seems good at the=20 > > first read,=20 > > > >> anyway. I > > > >> >>>>don't think there is a need for the non-type=20 > > specific size > > > >> >> > > > >> >>attribute. > > > >> >> > > > >> >>>>The only advantage would be to reduce size of=20 > the SDP. I > > > >> >>>>don't see that > > > >> >>>>as a big requirement, since it normally only=20 > happens one > > > >> >> > > > >> >>per session. > > > >> >> > > > >> >>>>Do others have thoughts on the matter? Do we need this > > > >> >> > > > >> >>feature at all? > > > >> >> > > > >> >>>> > > > >> >>>> > > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>>>Hi, > > > >> >>>>> > > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > > discussion I > > > >> >>>> > > > >> >>>>am bringing to the list the issue about being able to > > > >> >>>>indicate the max content size a node is able=20 > to receive. > > > >> >>>>Also, as input, in chapter 4 of > > > >> =20 > > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > >> >>>>a requirement for such functionality: > > > >> >>>> > > > >> >>>> > > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > the maximum > > > >> >>>> > > > >> >>>>message size it is willing to receive. > > > >> >>>> > > > >> >>>> > > > >> >>>>>I think it would be useful if clients could=20 > indicate the > > > >> >>>> > > > >> >>>>maximum payload size he is able to receive, and=20 > > also send, > > > >> >>>>either per type or stream. Note that I am=20 > > talking about the > > > >> >>>>total message/content size, not the size of individual > > > >> >>>>fragments (the spec does say that messages=20 > bigger than 2k > > > >> >>>>should be fragmented). > > > >> >>>> > > > >> >>>> > > > >> >>>>>If the max size is dependent on the media=20 > type, max size > > > >> >>>> > > > >> >>>>could be defined as a accept-type token paramter: > > > >> >>>> > > > >> >>>> > > > >> >>>>>example: > > > >> >>>>> > > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > > >> >>>> > > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > > >> >>>> > > > >> >>>> > > > >> >>>>>And, if the message size it not type dependent,=20 > > > generic max > > > >> >>>> > > > >> >>>>size attributes could be used. > > > >> >>>> > > > >> >>>> > > > >> >>>>>example: > > > >> >>>>> > > > >> >>>>>a=3Dmax-send: 1000 > > > >> >>>>>a=3Dmax-receive:1000 > > > >> >>>>> > > > >> >>>>>Even if one is not going to send more than the=20 > > other party > > > >> >>>> > > > >> >>>>indicates he is able to receive I still think it=20 > > > is important > > > >> >>>>that a node can indicate how much he is able=20 > to send. For > > > >> >>>>example, the remote node may reserve memory=20 > > > according to that > > > >> >>>>information, and/or intermediate proxies may do > > > >> >>>>forking/routing based on the client capabilities. > > > >> >>>> > > > >> >>>> > > > >> >>>>>An MSRP "message size too big" error code=20 > could also be > > > >> >>>> > > > >> >>>>useful, if a node for whatever reason is not able=20 > > > to accept a > > > >> >>>>SEND message. This may be due to that the=20 > remote node is > > > >> >>>>sending more data than was agreed in the=20 > > offer/answer, but > > > >> >>>>also due to that the receiving node for a short=20 > > > period isn't > > > >> >>>>able to receive the agreed data size (if the max=20 > > > size change > > > >> >>>>is permanent a new offer should of course be sent,=20 > > > instead of > > > >> >>>>sending an error reply to every SEND). At the=20 > > > interim meeting > > > >> >>>>is was desired to have a mechanism to "interrupt" the > > > >> >>>>receival of a message, and this error code could=20 > > be used to > > > >> >>>>indicate that. The sender would then stop sending the > > > >> >>>>message, and any possible yet unsent fragments. > > > >> >>>> > > > >> >>>> > > > >> >>>>>Regards, > > > >> >>>>> > > > >> >>>>>Christer Holmberg > > > >> >>>>>Ericsson Finland > > > >> >>>> > > > >> >>>> > > > >> >>>>_______________________________________________ > > > >> >>>>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 > > > >> > > > >> > > > >> > > > >> This message has been scanned for viruses by MailControl -=20 > > > >> www.mailcontrol.com > > > >> > > > >> > > > >> > > > >>=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 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 13:58:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12867 for ; Tue, 8 Jun 2004 13:58:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXksE-0006Ez-K4 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:58:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkr6-0005Oe-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 13:57:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXkqK-0004LS-00; Tue, 08 Jun 2004 13:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkbj-0002Kk-6c; Tue, 08 Jun 2004 13:41:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkUY-0008Ct-7U for simple@megatron.ietf.org; Tue, 08 Jun 2004 13:34: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 NAA10783 for ; Tue, 8 Jun 2004 13:34:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkUX-0003Yj-7G for simple@ietf.org; Tue, 08 Jun 2004 13:34:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkSp-0002Z7-00 for simple@ietf.org; Tue, 08 Jun 2004 13:32:45 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BXkRb-0001Qm-00 for simple@ietf.org; Tue, 08 Jun 2004 13:31:27 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58HVQWR002702 for ; Tue, 8 Jun 2004 19:31:26 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 19:31:26 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 19:31:26 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Ben Campbell'" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 19:31:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jun 2004 17:31:26.0732 (UTC) FILETIME=[6D3F9CC0:01C44D7E] Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, "'hisham.khartabil@nokia.com'" , cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Ben, I am pretty sure the main use of this would be for the end terminals. I = mentioned the routing proxies as another example where it could be = useful to have this information at setup time. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 8. kes=E4kuuta 2004 17:42 > To: Christer Holmberg (JO/LMF) > Cc: 'hisham.khartabil@nokia.com'; pkyzivat@cisco.com; > cboulton@ubiquity.com; simple@ietf.org > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > I don't want to get too deep in this until we have results on=20 > the "vote"=20 > (running neck and neck at the moment.) But to risk jumping into=20 > mechanism, comments inline: >=20 > Christer Holmberg (JO/LMF) wrote: >=20 > > Hi Hisham, > >=20 > >=20 > >>>The support and use of the attribute/parameter would be=20 > >>>OPTIONAL, so if a node doesn't support the=20 > >>>attribute/parameter (it is not able to calculate a value, it=20 > >>>can't be configured, or the node simply thinks that size=20 > >>>doesn't matter) everything will still work, as today, and it=20 > >>>will then be "local policy" what to do if the messages can't=20 > >>>be handled. > >> > >>So, You send me an offer with receive-max-size of 1500 bytes,=20 > >>but I don't understand that parameter. This doesn't help you.=20 > >>I send you a message with 1Meg and you have to reject it with=20 > >>a 4xx anyway. So where is the benefit of having this as optional? > >=20 > >=20 > > The benefit is that you may have scenarios or network=20 > architectures where this information is used (not only by the=20 > end terminals, but also by intermediate nodes) for making=20 > service/routing/etc decissions. Of course, a node may always=20 > send too large messages, which have to be rejected (using a=20 > 4xx response), but the idea is to have a mechanism where this=20 > can be avoided. If big messages are to be sent I think it is=20 > very useful to have this information, in order to adjust=20 > terminal settings, and to make the transmission smooth, and=20 > in order to send lots of stuff on the network that may be=20 > rejected (that data may then have to be retransmitted, using=20 > smaller messages, or the session may fail). >=20 > If this is something we expect proxies to use for routing=20 > decisions, we=20 > should consider doing it in the headers, rather than in the=20 > body. So, is=20 > there anything in caller-prefs that will help here? >=20 >=20 > > This is similar to any other SDP attribute. If you don't=20 > support it, you discard it, and things should work anyway -=20 > but IF you support it it may provide you with useful=20 > information for optimal performance. > >=20 > > However, IF people prefear making support mandatory, I=20 > personally don't have anything against that. But, that's not=20 > what I am proposing, because I do realize there may be=20 > scenarios where this kind of information is not needed.=20 > Another option is making it mandatory, and defining a default=20 > value if the information is not present (similar to the=20 > "sendrecv" media direction attribute), but that is not what I=20 > am proposing either. My issue is that I think it's useful to=20 > have this kind of information. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >>/Hisham > >> > >> > >>>Of course, a node can send a 4xx response if the message it=20 > >>>receives is too big, but as I said before, there may be=20 > >>>scenarios where the size information is used to make=20 > >>>decissions already at the session setup phase. > >>> > >>>As Andrew said, this feature is especially useful for mobile=20 > >>>devices, or other nodes with limited memory. > >>> > >>>And, since there is a requirement at least for the receiving=20 > >>>part, I assume it at some stage has been realized that the > >>>information could be useful. > >>> > >>>Regards, > >>> > >>>Christer Holmberg > >>>Ericsson Finland > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>Sent: 7. kes=E4kuuta 2004 19:55 > >>>>To: Ben Campbell > >>>>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > >>>>simple@ietf.org; Christer > >>>>Holmberg (JO/LMF) > >>>>Subject: Re: [Simple] Re: MSRP: Max message size indication > >>>> > >>>> > >>>>Ben, > >>>> > >>>> > >>>> Paul > >>>> > >>>>Ben Campbell wrote: > >>>> > >>>>>I'd like to try and get some closure on this: > >>>>> > >>>>>Please answer yes or no to the following: > >>>>> > >>>>>1) Should we add the optional signaling of the maximum=20 > >>>> > >>>>content size you=20 > >>>> > >>>>>are willing to _receive_ into the SDP exchange. > >>>>> > >>>>>2) Should we add the optional signaling of the maximum=20 > >>>> > >>>>content size you=20 > >>>> > >>>>>are planning to _send_ into the SDP exchange. > >>>>> > >>>>>3) If either 1 or 2 is yes, do we send one value for the=20 > >>>> > >>>>session, or one=20 > >>>> > >>>>>value per each type for which we have indicated support. > >>>>> > >>>>>My personal opinions: > >>>>> > >>>>>No and No. In all honesty, I think this could be a useful=20 > >>>> > >>>>feature, but I=20 > >>>> > >>>>>don't think MSRP has to have it to function. I am voting=20 > >>>> > >>>>no, not because=20 > >>>> > >>>>>I disagree with the feature, but because I don't want to=20 > >>>> > >>>>add additional=20 > >>>> > >>>>>work to completing MSRP unless it is absolutely=20 > >> > >>necessary. But if=20 > >> > >>>>>consensus says we need it, I do not object on any=20 > >> > >>technical basis. > >> > >>>>> > >>>>> > >>>>> > >>>>>Chris Boulton wrote: > >>>>> > >>>>> > >>>>>>I think this feature would certainly be useful for max=20 > >>>> > >>>>receive (if it=20 > >>>> > >>>>>>was type specific) BUT I am not convinced about send. > >>>>>>=20 > >>>>>>Chris. > >>>>>>=20 > >>>>>> > >>>>>> -----Original Message----- From: Ben Campbell=20 > >>>>>>[mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > >>> > >>>25/05/2004 18:27=20 > >>> > >>>>>> To: Christer Holmberg (JO/LMF) Cc:=20 > >>>> > >>>>hisham.khartabil@nokia.com;=20 > >>>> > >>>>>>simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > >>>> > >>>>message size=20 > >>>> > >>>>>>indication > >>>>>> =20 > >>>>>> =20 > >>>>>> > >>>>>> Let me step up a level: > >>>>>> =20 > >>>>>> By the required vs useful discussion, I was=20 > >> > >>referring to the=20 > >> > >>>>>>feature of > >>>>>> being able to signal size limitations itself, rather=20 > >>> > >>>than some=20 > >>> > >>>>>>aspect of > >>>>>> the feature. > >>>>>> =20 > >>>>>> So, what do others about whether the feature of being=20 > >>>> > >>>>able to signal > >>>> > >>>>>> message size limits is required? > >>>>>> =20 > >>>>>> Christer Holmberg (JO/LMF) wrote: > >>>>>> =20 > >>>>>> > Hi, > >>>>>> > > >>>>>> > > >>>>>> >>(Ignore my yet-another-empty reply. This time I=20 > >>>> > >>>>blame the combined > >>>> > >>>>>> >>ergonomics of Thunderbird and my laptop.) > >>>>>> >> > >>>>>> >>That brings up an interesting meta-question. What=20 > >>> > >>>is the bar > >>> > >>>>>> >>for putting new features into MSRP at this stage? Is=20 > >>>> > >>>>"useful"=20 > >>>> > >>>>>>enough? Or > >>>>>> >>should we limit new features to things that we=20 > >> > >>decide are=20 > >> > >>>>>>"required." > >>>>>> > > >>>>>> > > >>>>>> > Well, the max-receive is required, and I think=20 > >> > >>it is very=20 > >> > >>>>>>useful. As I wrote earlier, the question is if it should=20 > >>>> > >>>>be possible=20 > >>>> > >>>>>>to indicate separate values for different media types. > >>>>>> > > >>>>>> > The max-send is not required, but I still think it=20 > >>>> > >>>>would be very=20 > >>>> > >>>>>>useful. Earlier I gave some examples I think are very=20 > >>>> > >>>>valid (nodes may=20 > >>>> > >>>>>>try to reserve memory according to how much big messages=20 > >>> > >>>then can=20 > >>> > >>>>>>expect to receive, redirection/forking may be done=20 > >> > >>based on the=20 > >> > >>>>>>information etc etc etc). It wouldn't have any impacts on=20 > >>>> > >>>>the protocol=20 > >>>> > >>>>>>functionality itself, and there would be no interop=20 > >>> > >>>problems with=20 > >>> > >>>>>>nodes that don't understand the max-send=20 > >>>> > >>>>attribute/parameter (or just=20 > >>>> > >>>>>>don't care about it). > >>>>>> > > >>>>>> > Regards, > >>>>>> > > >>>>>> > Christer Holmberg > >>>>>> > Ericsson Finland > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> >>hisham.khartabil@nokia.com wrote: > >>>>>> >> > >>>>>> >> > >>>>>> >>>I think max-receive is useful, but not max-send. > >>>>>> >>> > >>>>>> >>>/Hisham > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>>-----Original Message----- > >>>>>> >>>>From: simple-bounces@ietf.org > >>>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>>>>> >>>>Of ext Ben Campbell > >>>>>> >>>>Sent: 25.May.2004 17:49 > >>>>>> >>>>To: Christer Holmberg (JO/LMF) > >>>>>> >>>>Cc: 'simple@ietf.org' > >>>>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > >>>> > >>>>on the subject.) > >>>> > >>>>>> >>>> > >>>>>> >>>>I do not have strong feelings on this as a=20 > >>>> > >>>>requirement. If we > >>>> > >>>>>> >>>>do want to > >>>>>> >>>>do it, the general approach seems good at the=20 > >>> > >>>first read,=20 > >>> > >>>>>>anyway. I > >>>>>> >>>>don't think there is a need for the non-type=20 > >>> > >>>specific size > >>> > >>>>>> >> > >>>>>> >>attribute. > >>>>>> >> > >>>>>> >>>>The only advantage would be to reduce size of=20 > >> > >>the SDP. I > >> > >>>>>> >>>>don't see that > >>>>>> >>>>as a big requirement, since it normally only=20 > >> > >>happens one > >> > >>>>>> >> > >>>>>> >>per session. > >>>>>> >> > >>>>>> >>>>Do others have thoughts on the matter? Do we need this > >>>>>> >> > >>>>>> >>feature at all? > >>>>>> >> > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>Christer Holmberg (JO/LMF) wrote: > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>Hi, > >>>>>> >>>>> > >>>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > >>> > >>>discussion I > >>> > >>>>>> >>>> > >>>>>> >>>>am bringing to the list the issue about being able to > >>>>>> >>>>indicate the max content size a node is able=20 > >> > >>to receive. > >> > >>>>>> >>>>Also, as input, in chapter 4 of > >>>>>> =20 > >>>>>> > >>>>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >>>>>> > >>>>>> >>>>a requirement for such functionality: > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > >> > >>the maximum > >> > >>>>>> >>>> > >>>>>> >>>>message size it is willing to receive. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>I think it would be useful if clients could=20 > >> > >>indicate the > >> > >>>>>> >>>> > >>>>>> >>>>maximum payload size he is able to receive, and=20 > >>> > >>>also send, > >>> > >>>>>> >>>>either per type or stream. Note that I am=20 > >>> > >>>talking about the > >>> > >>>>>> >>>>total message/content size, not the size of individual > >>>>>> >>>>fragments (the spec does say that messages=20 > >> > >>bigger than 2k > >> > >>>>>> >>>>should be fragmented). > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>If the max size is dependent on the media=20 > >> > >>type, max size > >> > >>>>>> >>>> > >>>>>> >>>>could be defined as a accept-type token paramter: > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>example: > >>>>>> >>>>> > >>>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >>>>>> >>>> > >>>>>> >>>>Y;max-send=3D2000;max-receive=3D500 > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>And, if the message size it not type dependent,=20 > >>>> > >>>>generic max > >>>> > >>>>>> >>>> > >>>>>> >>>>size attributes could be used. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>example: > >>>>>> >>>>> > >>>>>> >>>>>a=3Dmax-send: 1000 > >>>>>> >>>>>a=3Dmax-receive:1000 > >>>>>> >>>>> > >>>>>> >>>>>Even if one is not going to send more than the=20 > >>> > >>>other party > >>> > >>>>>> >>>> > >>>>>> >>>>indicates he is able to receive I still think it=20 > >>>> > >>>>is important > >>>> > >>>>>> >>>>that a node can indicate how much he is able=20 > >> > >>to send. For > >> > >>>>>> >>>>example, the remote node may reserve memory=20 > >>>> > >>>>according to that > >>>> > >>>>>> >>>>information, and/or intermediate proxies may do > >>>>>> >>>>forking/routing based on the client capabilities. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>An MSRP "message size too big" error code=20 > >> > >>could also be > >> > >>>>>> >>>> > >>>>>> >>>>useful, if a node for whatever reason is not able=20 > >>>> > >>>>to accept a > >>>> > >>>>>> >>>>SEND message. This may be due to that the=20 > >> > >>remote node is > >> > >>>>>> >>>>sending more data than was agreed in the=20 > >>> > >>>offer/answer, but > >>> > >>>>>> >>>>also due to that the receiving node for a short=20 > >>>> > >>>>period isn't > >>>> > >>>>>> >>>>able to receive the agreed data size (if the max=20 > >>>> > >>>>size change > >>>> > >>>>>> >>>>is permanent a new offer should of course be sent,=20 > >>>> > >>>>instead of > >>>> > >>>>>> >>>>sending an error reply to every SEND). At the=20 > >>>> > >>>>interim meeting > >>>> > >>>>>> >>>>is was desired to have a mechanism to "interrupt" the > >>>>>> >>>>receival of a message, and this error code could=20 > >>> > >>>be used to > >>> > >>>>>> >>>>indicate that. The sender would then stop sending the > >>>>>> >>>>message, and any possible yet unsent fragments. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>Regards, > >>>>>> >>>>> > >>>>>> >>>>>Christer Holmberg > >>>>>> >>>>>Ericsson Finland > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>_______________________________________________ > >>>>>> >>>>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 > >>>>>> > >>>>>> > >>>>>> > >>>>>>This message has been scanned for viruses by MailControl -=20 > >>>>>>www.mailcontrol.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 > >>>>> > >>>> >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 14:14:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13895 for ; Tue, 8 Jun 2004 14:14:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXl7c-0004G5-5f for simple-archive@ietf.org; Tue, 08 Jun 2004 14:14:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXl6Q-0003Ns-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 14:13:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXl56-0001ha-00; Tue, 08 Jun 2004 14:12:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkts-00088K-NB; Tue, 08 Jun 2004 14:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkhk-0003x7-26 for simple@megatron.ietf.org; Tue, 08 Jun 2004 13: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 NAA12369 for ; Tue, 8 Jun 2004 13:48:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkhj-0004ru-1R for simple@ietf.org; Tue, 08 Jun 2004 13:48:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkgn-00040R-00 for simple@ietf.org; Tue, 08 Jun 2004 13:47:11 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXkfj-00036c-00 for simple@ietf.org; Tue, 08 Jun 2004 13:46:03 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58Hk3Ah028890 for ; Tue, 8 Jun 2004 19:46:03 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 19:46:03 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 19:46:03 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'hisham.khartabil@nokia.com'" , drage@lucent.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 19:46:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 08 Jun 2004 17:46:03.0757 (UTC) FILETIME=[77FF01D0:01C44D80] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i58Hk3Ah028890 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Hisham, >Furthermore. If my terminal has 10Meg free memory and some=20 >logic decides that my IM session application gets 10% of that=20 >(1 Meg), so I signal max-receive-size of 1 Meg. >=20 >In the mean time, I have downloaded a 9 Meg mpeg from some=20 >sight. My quota for IMS session would now change to 100K. Do=20 >I resignal that max-receive-size has changed? [CHH] You MAY do so, using an updated offer, if you want to. I wrote some= text about that in my initial posts. =20 >Also, after I have signalled that the max-receive-size is=20 >1Meg, I receive a 1 Meg message and I accept it (since it did=20 >not exceed the 1Meg max size limit). Then I receive a second=20 >one of those 1 Meg messages, do I accept? [CHH] It's up to your implementation. The max-size attribute, even if sup= port would be mandatory, does NOT take away the need to be able to reject= a message, if one for whatever reason is not able to receive it. >What does max-receive-size really mean? Max size of messages=20 >in total in this session? Max size of 1 message?=20 [CHH] I think I in my initial post very clearly indicated that max size o= f 1 message - ie NOT the total size of all messages, and NOT the size of = a message fragment. >How can I ever possibly determine the maximum message size I can=20 >receive is? In any case, rejecting a message because of size=20 >needs to be supported. [CHH] Again, I agree. Others have said that, and I have said that. >Too many questions, too little time -> I vote no/no (not as a chair) [CHH] I have answered some of your questions. The other questions are val= id even without the max-size attribute, so they need to be solved anyway. Regards, Christer Holmberg Ericsson Finland >=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org=20 > > [mailto:simple-bounces@ietf.org]On Behalf > > Of ext Drage, Keith (Keith) > > Sent: 08.June.2004 16:51 > > To: Christer Holmberg (JO/LMF) > > Cc: simple@ietf.org > > Subject: RE: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > > Arguing that it is optional does not mean it should go into=20 > > an RFC with issues attached. We have to solve all the issues=20 > > even for optional capabilities, and even with restrictions,=20 > > to be be adopted, it must still be useful. > >=20 > > Our concern on this is that while a message receiver may know=20 > > the maximum size messages it can buffer, any message sender=20 > > would require an interaction with the use of the application=20 > > to decide what that maximum might be. In most, if not all=20 > > message sessions, that sending size might not be known until=20 > > the time it is required to send a message, and the overflow=20 > > may possibly not be known until the sender has started=20 > > sending the message. > >=20 > > Thus I see some need by the receiver of a message to abort a=20 > > message when the internal buffers get full. What happens then=20 > > - we still need to deal with this case even if a size is=20 > > negotiated. My assumption is that an application would do the=20 > > best to render what it has, accompanied by some meaningful=20 > > notation. Further recovery would then take place at the=20 > > application layer, e.g. a reply message saying "send your=20 > > message again without the picture because it was too big for=20 > > my receiver to handle".=20 > >=20 > > Now give that we have to do that anyway, do we gain any=20 > > advantage in the few cases where the future message size is=20 > > known at session establishment time. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF)=20 > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 07 June 2004 18:23 > > > To: 'Paul Kyzivat'; Ben Campbell > > > Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org > > > Subject: RE: [Simple] Re: MSRP: Max message size indication > > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > I disagree, and my answer is yes/yes. > > >=20 > > > >I'm inclined to agree with you (no/no). For many nodes this=20 > > > is simply=20 > > > >not a number that is easily decided. If anything, I imagine=20 > > > >it would be best to negotiate this. But that requires the=20 > > > sender to pick=20 > > > >a maximum send value, even though the sender probably has no=20 > > > particular limit.=20 > > > >This just seems like a rat hole best avoided for now. > > >=20 > > > The support and use of the attribute/parameter would be=20 > > > OPTIONAL, so if a node doesn't support the=20 > > > attribute/parameter (it is not able to calculate a value, it=20 > > > can't be configured, or the node simply thinks that size=20 > > > doesn't matter) everything will still work, as today, and it=20 > > > will then be "local policy" what to do if the messages can't=20 > > > be handled. > > >=20 > > > Of course, a node can send a 4xx response if the message it=20 > > > receives is too big, but as I said before, there may be=20 > > > scenarios where the size information is used to make=20 > > > decissions already at the session setup phase. > > >=20 > > > As Andrew said, this feature is especially useful for mobile=20 > > > devices, or other nodes with limited memory. > > >=20 > > > And, since there is a requirement at least for the receiving=20 > > > part, I assume it at some stage has been realized that the=20 > > > information could be useful. > > >=20 > > > Regards, > > >=20 > > > Christer Holmberg > > > Ericsson Finland > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: 7. kes=E4kuuta 2004 19:55 > > > > To: Ben Campbell > > > > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > > > > simple@ietf.org; Christer > > > > Holmberg (JO/LMF) > > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > >=20 > > > >=20 > > > > Ben, > > > >=20 > > > >=20 > > > > Paul > > > >=20 > > > > Ben Campbell wrote: > > > > > I'd like to try and get some closure on this: > > > > >=20 > > > > > Please answer yes or no to the following: > > > > >=20 > > > > > 1) Should we add the optional signaling of the maximum=20 > > > > content size you=20 > > > > > are willing to _receive_ into the SDP exchange. > > > > >=20 > > > > > 2) Should we add the optional signaling of the maximum=20 > > > > content size you=20 > > > > > are planning to _send_ into the SDP exchange. > > > > >=20 > > > > > 3) If either 1 or 2 is yes, do we send one value for the=20 > > > > session, or one=20 > > > > > value per each type for which we have indicated support. > > > > >=20 > > > > > My personal opinions: > > > > >=20 > > > > > No and No. In all honesty, I think this could be a useful=20 > > > > feature, but I=20 > > > > > don't think MSRP has to have it to function. I am voting=20 > > > > no, not because=20 > > > > > I disagree with the feature, but because I don't want to=20 > > > > add additional=20 > > > > > work to completing MSRP unless it is absolutely=20 > > necessary. But if=20 > > > > > consensus says we need it, I do not object on any=20 > > technical basis. > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Chris Boulton wrote: > > > > >=20 > > > > >> I think this feature would certainly be useful for max=20 > > > > receive (if it=20 > > > > >> was type specific) BUT I am not convinced about send. > > > > >> =20 > > > > >> Chris. > > > > >> =20 > > > > >> > > > > >> -----Original Message----- From: Ben Campbell=20 > > > > >> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > > > 25/05/2004 18:27=20 > > > > >> To: Christer Holmberg (JO/LMF) Cc:=20 > > > > hisham.khartabil@nokia.com;=20 > > > > >> simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 > > > > message size=20 > > > > >> indication > > > > >> =20 > > > > >> =20 > > > > >> > > > > >> Let me step up a level: > > > > >> =20 > > > > >> By the required vs useful discussion, I was=20 > > referring to the=20 > > > > >> feature of > > > > >> being able to signal size limitations itself, rather=20 > > > than some=20 > > > > >> aspect of > > > > >> the feature. > > > > >> =20 > > > > >> So, what do others about whether the feature of being=20 > > > > able to signal > > > > >> message size limits is required? > > > > >> =20 > > > > >> Christer Holmberg (JO/LMF) wrote: > > > > >> =20 > > > > >> > Hi, > > > > >> > > > > > >> > > > > > >> >>(Ignore my yet-another-empty reply. This time I=20 > > > > blame the combined > > > > >> >>ergonomics of Thunderbird and my laptop.) > > > > >> >> > > > > >> >>That brings up an interesting meta-question. What=20 > > > is the bar > > > > >> >>for putting new features into MSRP at this stage? Is=20 > > > > "useful"=20 > > > > >> enough? Or > > > > >> >>should we limit new features to things that we=20 > > decide are=20 > > > > >> "required." > > > > >> > > > > > >> > > > > > >> > Well, the max-receive is required, and I think=20 > > it is very=20 > > > > >> useful. As I wrote earlier, the question is if it should=20 > > > > be possible=20 > > > > >> to indicate separate values for different media types. > > > > >> > > > > > >> > The max-send is not required, but I still think it=20 > > > > would be very=20 > > > > >> useful. Earlier I gave some examples I think are very=20 > > > > valid (nodes may=20 > > > > >> try to reserve memory according to how much big messages=20 > > > then can=20 > > > > >> expect to receive, redirection/forking may be done=20 > > based on the=20 > > > > >> information etc etc etc). It wouldn't have any impacts on=20 > > > > the protocol=20 > > > > >> functionality itself, and there would be no interop=20 > > > problems with=20 > > > > >> nodes that don't understand the max-send=20 > > > > attribute/parameter (or just=20 > > > > >> don't care about it). > > > > >> > > > > > >> > Regards, > > > > >> > > > > > >> > Christer Holmberg > > > > >> > Ericsson Finland > > > > >> > > > > > >> > > > > > >> > > > > > >> >>hisham.khartabil@nokia.com wrote: > > > > >> >> > > > > >> >> > > > > >> >>>I think max-receive is useful, but not max-send. > > > > >> >>> > > > > >> >>>/Hisham > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > >> >>>>-----Original Message----- > > > > >> >>>>From: simple-bounces@ietf.org > > > > >> >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > > >> >>>>Of ext Ben Campbell > > > > >> >>>>Sent: 25.May.2004 17:49 > > > > >> >>>>To: Christer Holmberg (JO/LMF) > > > > >> >>>>Cc: 'simple@ietf.org' > > > > >> >>>>Subject: [Simple] Re: MSRP: Max message size=20 > indication > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>(Oops, itchy trigger finger--ignore my last mail=20 > > > > on the subject.) > > > > >> >>>> > > > > >> >>>>I do not have strong feelings on this as a=20 > > > > requirement. If we > > > > >> >>>>do want to > > > > >> >>>>do it, the general approach seems good at the=20 > > > first read,=20 > > > > >> anyway. I > > > > >> >>>>don't think there is a need for the non-type=20 > > > specific size > > > > >> >> > > > > >> >>attribute. > > > > >> >> > > > > >> >>>>The only advantage would be to reduce size of=20 > > the SDP. I > > > > >> >>>>don't see that > > > > >> >>>>as a big requirement, since it normally only=20 > > happens one > > > > >> >> > > > > >> >>per session. > > > > >> >> > > > > >> >>>>Do others have thoughts on the matter? Do we=20 > need this > > > > >> >> > > > > >> >>feature at all? > > > > >> >> > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>Christer Holmberg (JO/LMF) wrote: > > > > >> >>>> > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>Hi, > > > > >> >>>>> > > > > >> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > > > discussion I > > > > >> >>>> > > > > >> >>>>am bringing to the list the issue about being able to > > > > >> >>>>indicate the max content size a node is able=20 > > to receive. > > > > >> >>>>Also, as input, in chapter 4 of > > > > >> =20 > > > >=20 > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > > >> >>>>a requirement for such functionality: > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > > the maximum > > > > >> >>>> > > > > >> >>>>message size it is willing to receive. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>I think it would be useful if clients could=20 > > indicate the > > > > >> >>>> > > > > >> >>>>maximum payload size he is able to receive, and=20 > > > also send, > > > > >> >>>>either per type or stream. Note that I am=20 > > > talking about the > > > > >> >>>>total message/content size, not the size of=20 > individual > > > > >> >>>>fragments (the spec does say that messages=20 > > bigger than 2k > > > > >> >>>>should be fragmented). > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>If the max size is dependent on the media=20 > > type, max size > > > > >> >>>> > > > > >> >>>>could be defined as a accept-type token paramter: > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>example: > > > > >> >>>>> > > > > >> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > > > > >> >>>> > > > > >> >>>>Y;max-send=3D2000;max-receive=3D500 > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>And, if the message size it not type dependent,=20 > > > > generic max > > > > >> >>>> > > > > >> >>>>size attributes could be used. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>example: > > > > >> >>>>> > > > > >> >>>>>a=3Dmax-send: 1000 > > > > >> >>>>>a=3Dmax-receive:1000 > > > > >> >>>>> > > > > >> >>>>>Even if one is not going to send more than the=20 > > > other party > > > > >> >>>> > > > > >> >>>>indicates he is able to receive I still think it=20 > > > > is important > > > > >> >>>>that a node can indicate how much he is able=20 > > to send. For > > > > >> >>>>example, the remote node may reserve memory=20 > > > > according to that > > > > >> >>>>information, and/or intermediate proxies may do > > > > >> >>>>forking/routing based on the client capabilities. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>An MSRP "message size too big" error code=20 > > could also be > > > > >> >>>> > > > > >> >>>>useful, if a node for whatever reason is not able=20 > > > > to accept a > > > > >> >>>>SEND message. This may be due to that the=20 > > remote node is > > > > >> >>>>sending more data than was agreed in the=20 > > > offer/answer, but > > > > >> >>>>also due to that the receiving node for a short=20 > > > > period isn't > > > > >> >>>>able to receive the agreed data size (if the max=20 > > > > size change > > > > >> >>>>is permanent a new offer should of course be sent,=20 > > > > instead of > > > > >> >>>>sending an error reply to every SEND). At the=20 > > > > interim meeting > > > > >> >>>>is was desired to have a mechanism to "interrupt" the > > > > >> >>>>receival of a message, and this error code could=20 > > > be used to > > > > >> >>>>indicate that. The sender would then stop sending the > > > > >> >>>>message, and any possible yet unsent fragments. > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>>Regards, > > > > >> >>>>> > > > > >> >>>>>Christer Holmberg > > > > >> >>>>>Ericsson Finland > > > > >> >>>> > > > > >> >>>> > > > > >> >>>>_______________________________________________ > > > > >> >>>>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 > > > > >> > > > > >> > > > > >> > > > > >> This message has been scanned for viruses by MailControl -=20 > > > > >> www.mailcontrol.com > > > > >> > > > > >> > > > > >> > > > > >>=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 > > >=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 From simple-bounces@ietf.org Tue Jun 8 14:15:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14013 for ; Tue, 8 Jun 2004 14:15:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXl8Z-00056v-7t for simple-archive@ietf.org; Tue, 08 Jun 2004 14:15:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXl7V-0004FR-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 14:14:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXl6C-0002Yw-00; Tue, 08 Jun 2004 14:13:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXktu-000898-0X; Tue, 08 Jun 2004 14:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkiW-00045m-JR for simple@megatron.ietf.org; Tue, 08 Jun 2004 13:48: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 NAA12417 for ; Tue, 8 Jun 2004 13:48:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkiV-0005hU-JS for simple@ietf.org; Tue, 08 Jun 2004 13:48:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkhT-0004q2-00 for simple@ietf.org; Tue, 08 Jun 2004 13:47:53 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXkgV-0003Eq-00 for simple@ietf.org; Tue, 08 Jun 2004 13:46:51 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i58HkILp026833; Tue, 8 Jun 2004 12:46:18 -0500 Message-ID: <40C5FB62.9020204@dynamicsoft.com> Date: Tue, 08 Jun 2004 12:46:10 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Re: MSRP: Max message size indication References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> <40C489F9.1010706@dynamicsoft.com> <1086712308.6399.3551.camel@esdhcp09nok08184.ntc.nokia.com> In-Reply-To: <1086712308.6399.3551.camel@esdhcp09nok08184.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit So far, I have had 4 people (counting myself) respond no/no, 2 respond yes/yes, and one equivocation that I interpret as yes/no. This is a pretty small fraction of the work group. If only seven people care enough to even comment, I'm not sure we have a mandate for this. So, if there is anyone out there who cares but has not said so, please do so soon. Aki Niemi wrote: > I'll have to vote for no/no. I don't think it solves the real problem, > which is not having the sender/recipient ability to abort transfer > mid-message. > > Cheers, > Aki > > On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > >>I'd like to try and get some closure on this: >> >>Please answer yes or no to the following: >> >>1) Should we add the optional signaling of the maximum content size you >>are willing to _receive_ into the SDP exchange. >> >>2) Should we add the optional signaling of the maximum content size you >>are planning to _send_ into the SDP exchange. >> >>3) If either 1 or 2 is yes, do we send one value for the session, or one >>value per each type for which we have indicated support. >> >>My personal opinions: >> >>No and No. In all honesty, I think this could be a useful feature, but I >>don't think MSRP has to have it to function. I am voting no, not because >>I disagree with the feature, but because I don't want to add additional >>work to completing MSRP unless it is absolutely necessary. But if >>consensus says we need it, I do not object on any technical basis. >> >> >> >> >>Chris Boulton wrote: >> >> >>>I think this feature would certainly be useful for max receive (if it was type specific) BUT I am not convinced about send. >>> >>>Chris. >>> >>> >>> -----Original Message----- >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> Sent: Tue 25/05/2004 18:27 >>> To: Christer Holmberg (JO/LMF) >>> Cc: hisham.khartabil@nokia.com; simple@ietf.org >>> Subject: Re: [Simple] Re: MSRP: Max message size indication >>> >>> >>> >>> Let me step up a level: >>> >>> By the required vs useful discussion, I was referring to the feature of >>> being able to signal size limitations itself, rather than some aspect of >>> the feature. >>> >>> So, what do others about whether the feature of being able to signal >>> message size limits is required? >>> >>> Christer Holmberg (JO/LMF) wrote: >>> >>> > Hi, >>> > >>> > >>> >>(Ignore my yet-another-empty reply. This time I blame the combined >>> >>ergonomics of Thunderbird and my laptop.) >>> >> >>> >>That brings up an interesting meta-question. What is the bar >>> >>for putting new features into MSRP at this stage? Is "useful" enough? Or >>> >>should we limit new features to things that we decide are "required." >>> > >>> > >>> > Well, the max-receive is required, and I think it is very useful. As I wrote earlier, the question is if it should be possible to indicate separate values for different media types. >>> > >>> > The max-send is not required, but I still think it would be very useful. Earlier I gave some examples I think are very valid (nodes may try to reserve memory according to how much big messages then can expect to receive, redirection/forking may be done based on the information etc etc etc). It wouldn't have any impacts on the protocol functionality itself, and there would be no interop problems with nodes that don't understand the max-send attribute/parameter (or just don't care about it). >>> > >>> > Regards, >>> > >>> > Christer Holmberg >>> > Ericsson Finland >>> > >>> > >>> > >>> >>hisham.khartabil@nokia.com wrote: >>> >> >>> >> >>> >>>I think max-receive is useful, but not max-send. >>> >>> >>> >>>/Hisham >>> >>> >>> >>> >>> >>> >>> >>>>-----Original Message----- >>> >>>>From: simple-bounces@ietf.org >>> >>>>[mailto:simple-bounces@ietf.org]On Behalf >>> >>>>Of ext Ben Campbell >>> >>>>Sent: 25.May.2004 17:49 >>> >>>>To: Christer Holmberg (JO/LMF) >>> >>>>Cc: 'simple@ietf.org' >>> >>>>Subject: [Simple] Re: MSRP: Max message size indication >>> >>>> >>> >>>> >>> >>>>(Oops, itchy trigger finger--ignore my last mail on the subject.) >>> >>>> >>> >>>>I do not have strong feelings on this as a requirement. If we >>> >>>>do want to >>> >>>>do it, the general approach seems good at the first read, anyway. I >>> >>>>don't think there is a need for the non-type specific size >>> >> >>> >>attribute. >>> >> >>> >>>>The only advantage would be to reduce size of the SDP. I >>> >>>>don't see that >>> >>>>as a big requirement, since it normally only happens one >>> >> >>> >>per session. >>> >> >>> >>>>Do others have thoughts on the matter? Do we need this >>> >> >>> >>feature at all? >>> >> >>> >>>> >>> >>>> >>> >>>>Christer Holmberg (JO/LMF) wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>>>Hi, >>> >>>>> >>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I >>> >>>> >>> >>>>am bringing to the list the issue about being able to >>> >>>>indicate the max content size a node is able to receive. >>> >>>>Also, as input, in chapter 4 of >>> >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is >>> >>>>a requirement for such functionality: >>> >>>> >>> >>>> >>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum >>> >>>> >>> >>>>message size it is willing to receive. >>> >>>> >>> >>>> >>> >>>>>I think it would be useful if clients could indicate the >>> >>>> >>> >>>>maximum payload size he is able to receive, and also send, >>> >>>>either per type or stream. Note that I am talking about the >>> >>>>total message/content size, not the size of individual >>> >>>>fragments (the spec does say that messages bigger than 2k >>> >>>>should be fragmented). >>> >>>> >>> >>>> >>> >>>>>If the max size is dependent on the media type, max size >>> >>>> >>> >>>>could be defined as a accept-type token paramter: >>> >>>> >>> >>>> >>> >>>>>example: >>> >>>>> >>> >>>>>accept-type: X;max-send=1000;max-receive=1000, >>> >>>> >>> >>>>Y;max-send=2000;max-receive=500 >>> >>>> >>> >>>> >>> >>>>>And, if the message size it not type dependent, generic max >>> >>>> >>> >>>>size attributes could be used. >>> >>>> >>> >>>> >>> >>>>>example: >>> >>>>> >>> >>>>>a=max-send: 1000 >>> >>>>>a=max-receive:1000 >>> >>>>> >>> >>>>>Even if one is not going to send more than the other party >>> >>>> >>> >>>>indicates he is able to receive I still think it is important >>> >>>>that a node can indicate how much he is able to send. For >>> >>>>example, the remote node may reserve memory according to that >>> >>>>information, and/or intermediate proxies may do >>> >>>>forking/routing based on the client capabilities. >>> >>>> >>> >>>> >>> >>>>>An MSRP "message size too big" error code could also be >>> >>>> >>> >>>>useful, if a node for whatever reason is not able to accept a >>> >>>>SEND message. This may be due to that the remote node is >>> >>>>sending more data than was agreed in the offer/answer, but >>> >>>>also due to that the receiving node for a short period isn't >>> >>>>able to receive the agreed data size (if the max size change >>> >>>>is permanent a new offer should of course be sent, instead of >>> >>>>sending an error reply to every SEND). At the interim meeting >>> >>>>is was desired to have a mechanism to "interrupt" the >>> >>>>receival of a message, and this error code could be used to >>> >>>>indicate that. The sender would then stop sending the >>> >>>>message, and any possible yet unsent fragments. >>> >>>> >>> >>>> >>> >>>>>Regards, >>> >>>>> >>> >>>>>Christer Holmberg >>> >>>>>Ericsson Finland >>> >>>> >>> >>>> >>> >>>>_______________________________________________ >>> >>>>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 >>> >>> >>> >>> >>>This message has been scanned for viruses by MailControl - www.mailcontrol.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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 14:21:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14251 for ; Tue, 8 Jun 2004 14:21:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXlDo-0001cw-Cs for simple-archive@ietf.org; Tue, 08 Jun 2004 14:21:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXlCR-0000gZ-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 14:19:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXlBF-0006nj-00; Tue, 08 Jun 2004 14:18:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkvQ-0000mP-Is; Tue, 08 Jun 2004 14:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkq5-0006H1-Eb for simple@megatron.ietf.org; Tue, 08 Jun 2004 13:56: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 NAA12782 for ; Tue, 8 Jun 2004 13:56:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkq4-0004Z6-H2 for simple@ietf.org; Tue, 08 Jun 2004 13:56:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkp8-0003kS-00 for simple@ietf.org; Tue, 08 Jun 2004 13:55:48 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXko9-0002vV-00 for simple@ietf.org; Tue, 08 Jun 2004 13:54:46 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58HsjAh029629 for ; Tue, 8 Jun 2004 19:54:45 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 19:54:45 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 19:54:45 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Aki Niemi'" , ext Ben Campbell Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 19:54:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 08 Jun 2004 17:54:45.0597 (UTC) FILETIME=[AF0978D0:01C44D81] Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Aki, >I'll have to vote for no/no. I don't think it solves the real problem, >which is not having the sender/recipient ability to abort transfer >mid-message. I never said this will solve all problems :) Again, the idea is to reduce the situations where you would have to reject a message, but of course you still will need a mechanism for that. Regards, Christer Holmberg Ericsson Finland > > Cheers, > Aki > > On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > > I'd like to try and get some closure on this: > > > > Please answer yes or no to the following: > > > > 1) Should we add the optional signaling of the maximum > content size you > > are willing to _receive_ into the SDP exchange. > > > > 2) Should we add the optional signaling of the maximum > content size you > > are planning to _send_ into the SDP exchange. > > > > 3) If either 1 or 2 is yes, do we send one value for the > session, or one > > value per each type for which we have indicated support. > > > > My personal opinions: > > > > No and No. In all honesty, I think this could be a useful > feature, but I > > don't think MSRP has to have it to function. I am voting > no, not because > > I disagree with the feature, but because I don't want to > add additional > > work to completing MSRP unless it is absolutely necessary. But if > > consensus says we need it, I do not object on any technical basis. > > > > > > > > > > Chris Boulton wrote: > > > > > I think this feature would certainly be useful for max > receive (if it was type specific) BUT I am not convinced about send. > > > > > > Chris. > > > > > > > > > -----Original Message----- > > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: Tue 25/05/2004 18:27 > > > To: Christer Holmberg (JO/LMF) > > > Cc: hisham.khartabil@nokia.com; simple@ietf.org > > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > > > > > > > > > > Let me step up a level: > > > > > > By the required vs useful discussion, I was referring > to the feature of > > > being able to signal size limitations itself, rather > than some aspect of > > > the feature. > > > > > > So, what do others about whether the feature of being > able to signal > > > message size limits is required? > > > > > > Christer Holmberg (JO/LMF) wrote: > > > > > > > Hi, > > > > > > > > > > > >>(Ignore my yet-another-empty reply. This time I blame > the combined > > > >>ergonomics of Thunderbird and my laptop.) > > > >> > > > >>That brings up an interesting meta-question. What is the bar > > > >>for putting new features into MSRP at this stage? Is > "useful" enough? Or > > > >>should we limit new features to things that we decide > are "required." > > > > > > > > > > > > Well, the max-receive is required, and I think it is > very useful. As I wrote earlier, the question is if it should > be possible to indicate separate values for different media types. > > > > > > > > The max-send is not required, but I still think it > would be very useful. Earlier I gave some examples I think > are very valid (nodes may try to reserve memory according to > how much big messages then can expect to receive, > redirection/forking may be done based on the information etc > etc etc). It wouldn't have any impacts on the protocol > functionality itself, and there would be no interop problems > with nodes that don't understand the max-send > attribute/parameter (or just don't care about it). > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > >>hisham.khartabil@nokia.com wrote: > > > >> > > > >> > > > >>>I think max-receive is useful, but not max-send. > > > >>> > > > >>>/Hisham > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: simple-bounces@ietf.org > > > >>>>[mailto:simple-bounces@ietf.org]On Behalf > > > >>>>Of ext Ben Campbell > > > >>>>Sent: 25.May.2004 17:49 > > > >>>>To: Christer Holmberg (JO/LMF) > > > >>>>Cc: 'simple@ietf.org' > > > >>>>Subject: [Simple] Re: MSRP: Max message size indication > > > >>>> > > > >>>> > > > >>>>(Oops, itchy trigger finger--ignore my last mail on > the subject.) > > > >>>> > > > >>>>I do not have strong feelings on this as a > requirement. If we > > > >>>>do want to > > > >>>>do it, the general approach seems good at the first > read, anyway. I > > > >>>>don't think there is a need for the non-type specific size > > > >> > > > >>attribute. > > > >> > > > >>>>The only advantage would be to reduce size of the SDP. I > > > >>>>don't see that > > > >>>>as a big requirement, since it normally only happens one > > > >> > > > >>per session. > > > >> > > > >>>>Do others have thoughts on the matter? Do we need this > > > >> > > > >>feature at all? > > > >> > > > >>>> > > > >>>> > > > >>>>Christer Holmberg (JO/LMF) wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>>>Hi, > > > >>>>> > > > >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > > > >>>> > > > >>>>am bringing to the list the issue about being able to > > > >>>>indicate the max content size a node is able to receive. > > > >>>>Also, as input, in chapter 4 of > > > > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > > > >>>>a requirement for such functionality: > > > >>>> > > > >>>> > > > >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > > > >>>> > > > >>>>message size it is willing to receive. > > > >>>> > > > >>>> > > > >>>>>I think it would be useful if clients could indicate the > > > >>>> > > > >>>>maximum payload size he is able to receive, and also send, > > > >>>>either per type or stream. Note that I am talking about the > > > >>>>total message/content size, not the size of individual > > > >>>>fragments (the spec does say that messages bigger than 2k > > > >>>>should be fragmented). > > > >>>> > > > >>>> > > > >>>>>If the max size is dependent on the media type, max size > > > >>>> > > > >>>>could be defined as a accept-type token paramter: > > > >>>> > > > >>>> > > > >>>>>example: > > > >>>>> > > > >>>>>accept-type: X;max-send=1000;max-receive=1000, > > > >>>> > > > >>>>Y;max-send=2000;max-receive=500 > > > >>>> > > > >>>> > > > >>>>>And, if the message size it not type dependent, generic max > > > >>>> > > > >>>>size attributes could be used. > > > >>>> > > > >>>> > > > >>>>>example: > > > >>>>> > > > >>>>>a=max-send: 1000 > > > >>>>>a=max-receive:1000 > > > >>>>> > > > >>>>>Even if one is not going to send more than the other party > > > >>>> > > > >>>>indicates he is able to receive I still think it is > important > > > >>>>that a node can indicate how much he is able to send. For > > > >>>>example, the remote node may reserve memory > according to that > > > >>>>information, and/or intermediate proxies may do > > > >>>>forking/routing based on the client capabilities. > > > >>>> > > > >>>> > > > >>>>>An MSRP "message size too big" error code could also be > > > >>>> > > > >>>>useful, if a node for whatever reason is not able > to accept a > > > >>>>SEND message. This may be due to that the remote node is > > > >>>>sending more data than was agreed in the offer/answer, but > > > >>>>also due to that the receiving node for a short period isn't > > > >>>>able to receive the agreed data size (if the max size change > > > >>>>is permanent a new offer should of course be sent, > instead of > > > >>>>sending an error reply to every SEND). At the > interim meeting > > > >>>>is was desired to have a mechanism to "interrupt" the > > > >>>>receival of a message, and this error code could be used to > > > >>>>indicate that. The sender would then stop sending the > > > >>>>message, and any possible yet unsent fragments. > > > >>>> > > > >>>> > > > >>>>>Regards, > > > >>>>> > > > >>>>>Christer Holmberg > > > >>>>>Ericsson Finland > > > >>>> > > > >>>> > > > >>>>_______________________________________________ > > > >>>>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 > > > > > > > > > > > > > > > This message has been scanned for viruses by MailControl > - www.mailcontrol.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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 16:18:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21457 for ; Tue, 8 Jun 2004 16:18:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXn3d-0007VT-1d for simple-archive@ietf.org; Tue, 08 Jun 2004 16:18:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXn2W-0006dy-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 16:17:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXn1J-0004y1-00; Tue, 08 Jun 2004 16:16:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXmwK-0005TR-8A; Tue, 08 Jun 2004 16:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXlZW-00044a-Ru for simple@megatron.ietf.org; Tue, 08 Jun 2004 14:43: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 OAA15491 for ; Tue, 8 Jun 2004 14:43:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXlZV-000598-IY for simple@ietf.org; Tue, 08 Jun 2004 14:43:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXlYV-0004Jx-00 for simple@ietf.org; Tue, 08 Jun 2004 14:42:41 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BXlXH-00030k-00 for simple@ietf.org; Tue, 08 Jun 2004 14:41:23 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58IfJAh000442 for ; Tue, 8 Jun 2004 20:41:23 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 20:41:19 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 20:41:19 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Ben Campbell'" , Aki Niemi Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 20:41:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jun 2004 18:41:19.0773 (UTC) FILETIME=[307EE4D0:01C44D88] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Ben, If for no other reason (ie if nobody thinks the usage examples I've = given are valid), I think the requirement (REQ-CONTENT-1) is the = "mandate" we need. Or, have I missunderstood the requirment? Of course = the meaning of the requirement could be that one should be able to = indicate the size in an error response, but the text about = offer/answer, and that negotiation is needed , at least to me sounds = that negotiation is what it's really about. Now, of course, if there are technical reasons and/or big problems why = a requirement can not be fullfilled we need to re-visit the = requirments, and possibly change/remove something. But, so far most of = the comments have been about that fact that this doesn't solve the = issue when messages need to be rejected. However, the max-size = attribute is not supposed to solve that issue, and the requirment says = nothing about that issue, so I don't see why we should remove a = requirement just because it doesn't solve something it's not even = supposed to solve... If we remove requirements just becuase we suddenly don't think they are = needed I wonder how much work we have put on the requirements in the = first place, especially when we have came this far with the actual = protocol.=20 HOWEVER, I would really not like to use the requirements as an = argument, and I really hope we all think we have stable requirements - = instead I have tried to describe the technical reasons why I think this = would be useful. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 8. kes=E4kuuta 2004 20:46 > To: Aki Niemi > Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > simple@ietf.org; Christer > Holmberg (JO/LMF) > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > So far, I have had 4 people (counting myself) respond no/no,=20 > 2 respond=20 > yes/yes, and one equivocation that I interpret as yes/no. >=20 > This is a pretty small fraction of the work group. If only=20 > seven people=20 > care enough to even comment, I'm not sure we have a mandate for this. >=20 > So, if there is anyone out there who cares but has not said=20 > so, please=20 > do so soon. >=20 > Aki Niemi wrote: >=20 > > I'll have to vote for no/no. I don't think it solves the=20 > real problem, > > which is not having the sender/recipient ability to abort transfer > > mid-message. > >=20 > > Cheers, > > Aki > >=20 > > On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > >=20 > >>I'd like to try and get some closure on this: > >> > >>Please answer yes or no to the following: > >> > >>1) Should we add the optional signaling of the maximum=20 > content size you=20 > >>are willing to _receive_ into the SDP exchange. > >> > >>2) Should we add the optional signaling of the maximum=20 > content size you=20 > >>are planning to _send_ into the SDP exchange. > >> > >>3) If either 1 or 2 is yes, do we send one value for the=20 > session, or one=20 > >>value per each type for which we have indicated support. > >> > >>My personal opinions: > >> > >>No and No. In all honesty, I think this could be a useful=20 > feature, but I=20 > >>don't think MSRP has to have it to function. I am voting=20 > no, not because=20 > >>I disagree with the feature, but because I don't want to=20 > add additional=20 > >>work to completing MSRP unless it is absolutely necessary. But if=20 > >>consensus says we need it, I do not object on any technical basis. > >> > >> > >> > >> > >>Chris Boulton wrote: > >> > >> > >>>I think this feature would certainly be useful for max=20 > receive (if it was type specific) BUT I am not convinced about send. > >>>=20 > >>>Chris. > >>>=20 > >>> > >>> -----Original Message-----=20 > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > >>> Sent: Tue 25/05/2004 18:27 > >>> To: Christer Holmberg (JO/LMF)=20 > >>> Cc: hisham.khartabil@nokia.com; simple@ietf.org=20 > >>> Subject: Re: [Simple] Re: MSRP: Max message size indication > >>>=09 > >>>=09 > >>> > >>> Let me step up a level: > >>>=09 > >>> By the required vs useful discussion, I was referring=20 > to the feature of > >>> being able to signal size limitations itself, rather=20 > than some aspect of > >>> the feature. > >>>=09 > >>> So, what do others about whether the feature of being=20 > able to signal > >>> message size limits is required? > >>>=09 > >>> Christer Holmberg (JO/LMF) wrote: > >>>=09 > >>> > Hi, > >>> > > >>> > > >>> >>(Ignore my yet-another-empty reply. This time I blame=20 > the combined > >>> >>ergonomics of Thunderbird and my laptop.) > >>> >> > >>> >>That brings up an interesting meta-question. What is the bar > >>> >>for putting new features into MSRP at this stage? Is=20 > "useful" enough? Or > >>> >>should we limit new features to things that we decide=20 > are "required." > >>> > > >>> > > >>> > Well, the max-receive is required, and I think it is=20 > very useful. As I wrote earlier, the question is if it should=20 > be possible to indicate separate values for different media types. > >>> > > >>> > The max-send is not required, but I still think it=20 > would be very useful. Earlier I gave some examples I think=20 > are very valid (nodes may try to reserve memory according to=20 > how much big messages then can expect to receive,=20 > redirection/forking may be done based on the information etc=20 > etc etc). It wouldn't have any impacts on the protocol=20 > functionality itself, and there would be no interop problems=20 > with nodes that don't understand the max-send=20 > attribute/parameter (or just don't care about it). > >>> > > >>> > Regards, > >>> > > >>> > Christer Holmberg > >>> > Ericsson Finland > >>> > > >>> > > >>> > > >>> >>hisham.khartabil@nokia.com wrote: > >>> >> > >>> >> > >>> >>>I think max-receive is useful, but not max-send. > >>> >>> > >>> >>>/Hisham > >>> >>> > >>> >>> > >>> >>> > >>> >>>>-----Original Message----- > >>> >>>>From: simple-bounces@ietf.org > >>> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>> >>>>Of ext Ben Campbell > >>> >>>>Sent: 25.May.2004 17:49 > >>> >>>>To: Christer Holmberg (JO/LMF) > >>> >>>>Cc: 'simple@ietf.org' > >>> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >>> >>>> > >>> >>>> > >>> >>>>(Oops, itchy trigger finger--ignore my last mail on=20 > the subject.) > >>> >>>> > >>> >>>>I do not have strong feelings on this as a=20 > requirement. If we > >>> >>>>do want to > >>> >>>>do it, the general approach seems good at the first=20 > read, anyway. I > >>> >>>>don't think there is a need for the non-type specific size > >>> >> > >>> >>attribute. > >>> >> > >>> >>>>The only advantage would be to reduce size of the SDP. I > >>> >>>>don't see that > >>> >>>>as a big requirement, since it normally only happens one > >>> >> > >>> >>per session. > >>> >> > >>> >>>>Do others have thoughts on the matter? Do we need this > >>> >> > >>> >>feature at all? > >>> >> > >>> >>>> > >>> >>>> > >>> >>>>Christer Holmberg (JO/LMF) wrote: > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>>>Hi, > >>> >>>>> > >>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > >>> >>>> > >>> >>>>am bringing to the list the issue about being able to > >>> >>>>indicate the max content size a node is able to receive. > >>> >>>>Also, as input, in chapter 4 of > >>>=09 > >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >>> >>>>a requirement for such functionality: > >>> >>>> > >>> >>>> > >>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >>> >>>> > >>> >>>>message size it is willing to receive. > >>> >>>> > >>> >>>> > >>> >>>>>I think it would be useful if clients could indicate the > >>> >>>> > >>> >>>>maximum payload size he is able to receive, and also send, > >>> >>>>either per type or stream. Note that I am talking about the > >>> >>>>total message/content size, not the size of individual > >>> >>>>fragments (the spec does say that messages bigger than 2k > >>> >>>>should be fragmented). > >>> >>>> > >>> >>>> > >>> >>>>>If the max size is dependent on the media type, max size > >>> >>>> > >>> >>>>could be defined as a accept-type token paramter: > >>> >>>> > >>> >>>> > >>> >>>>>example: > >>> >>>>> > >>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >>> >>>> > >>> >>>>Y;max-send=3D2000;max-receive=3D500 > >>> >>>> > >>> >>>> > >>> >>>>>And, if the message size it not type dependent, generic max > >>> >>>> > >>> >>>>size attributes could be used. > >>> >>>> > >>> >>>> > >>> >>>>>example: > >>> >>>>> > >>> >>>>>a=3Dmax-send: 1000 > >>> >>>>>a=3Dmax-receive:1000 > >>> >>>>> > >>> >>>>>Even if one is not going to send more than the other party > >>> >>>> > >>> >>>>indicates he is able to receive I still think it is=20 > important > >>> >>>>that a node can indicate how much he is able to send. For > >>> >>>>example, the remote node may reserve memory=20 > according to that > >>> >>>>information, and/or intermediate proxies may do > >>> >>>>forking/routing based on the client capabilities. > >>> >>>> > >>> >>>> > >>> >>>>>An MSRP "message size too big" error code could also be > >>> >>>> > >>> >>>>useful, if a node for whatever reason is not able=20 > to accept a > >>> >>>>SEND message. This may be due to that the remote node is > >>> >>>>sending more data than was agreed in the offer/answer, but > >>> >>>>also due to that the receiving node for a short period isn't > >>> >>>>able to receive the agreed data size (if the max size change > >>> >>>>is permanent a new offer should of course be sent,=20 > instead of > >>> >>>>sending an error reply to every SEND). At the=20 > interim meeting > >>> >>>>is was desired to have a mechanism to "interrupt" the > >>> >>>>receival of a message, and this error code could be used to > >>> >>>>indicate that. The sender would then stop sending the > >>> >>>>message, and any possible yet unsent fragments. > >>> >>>> > >>> >>>> > >>> >>>>>Regards, > >>> >>>>> > >>> >>>>>Christer Holmberg > >>> >>>>>Ericsson Finland > >>> >>>> > >>> >>>> > >>> >>>>_______________________________________________ > >>> >>>>Simple mailing list > >>> >>>>Simple@ietf.org > >>> >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> >>>> > >>> >> > >>>=09 > >>>=09 > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >>>=09 > >>> > >>> > >>> > >>>This message has been scanned for viruses by MailControl -=20 www.mailcontrol.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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 17:55:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26503 for ; Tue, 8 Jun 2004 17:55:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoZ3-00060u-9w for simple-archive@ietf.org; Tue, 08 Jun 2004 17:55:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoTP-00038p-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 17:49:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXoQ0-0001CQ-00; Tue, 08 Jun 2004 17:46:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXoJh-0000O8-RQ; Tue, 08 Jun 2004 17:39:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXntG-00041i-1m; Tue, 08 Jun 2004 17:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXmPq-0005E9-6z for simple@megatron.ietf.org; Tue, 08 Jun 2004 15:37:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19375 for ; Tue, 8 Jun 2004 15:37:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXmPo-0003ZM-W3 for simple@ietf.org; Tue, 08 Jun 2004 15:37:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXmOq-0002jH-00 for simple@ietf.org; Tue, 08 Jun 2004 15:36:46 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXmNg-00013I-00 for simple@ietf.org; Tue, 08 Jun 2004 15:35:32 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i58JZ0Lp027184; Tue, 8 Jun 2004 14:35:00 -0500 Message-ID: <40C614DA.1040900@dynamicsoft.com> Date: Tue, 08 Jun 2004 14:34:50 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] Re: MSRP: Max message size indication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i58JZ0Lp027184 Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I just replied to a similar comment from Gonzalo. I had forgotten about=20 that requirement in the draft. That requirement seems to me to require=20 being able to indicate the max size you are willing to receive. It does=20 not seem to require indicating the max size you intend to send. Christer Holmberg (JO/LMF) wrote: > Hi Ben, >=20 > If for no other reason (ie if nobody thinks the usage examples I've giv= en are valid), I think the requirement (REQ-CONTENT-1) is the "mandate" w= e need. Or, have I missunderstood the requirment? Of course the meaning o= f the requirement could be that one should be able to indicate the size i= n an error response, but the text about offer/answer, and that negotiatio= n is needed , at least to me sounds that negotiation is what it's really = about. >=20 > Now, of course, if there are technical reasons and/or big problems why = a requirement can not be fullfilled we need to re-visit the requirments, = and possibly change/remove something. But, so far most of the comments ha= ve been about that fact that this doesn't solve the issue when messages n= eed to be rejected. However, the max-size attribute is not supposed to so= lve that issue, and the requirment says nothing about that issue, so I do= n't see why we should remove a requirement just because it doesn't solve = something it's not even supposed to solve... >=20 > If we remove requirements just becuase we suddenly don't think they are= needed I wonder how much work we have put on the requirements in the fir= st place, especially when we have came this far with the actual protocol.= =20 >=20 > HOWEVER, I would really not like to use the requirements as an argument= , and I really hope we all think we have stable requirements - instead I = have tried to describe the technical reasons why I think this would be us= eful. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 8. kes=E4kuuta 2004 20:46 >>To: Aki Niemi >>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 >>simple@ietf.org; Christer >>Holmberg (JO/LMF) >>Subject: Re: [Simple] Re: MSRP: Max message size indication >> >> >>So far, I have had 4 people (counting myself) respond no/no,=20 >>2 respond=20 >>yes/yes, and one equivocation that I interpret as yes/no. >> >>This is a pretty small fraction of the work group. If only=20 >>seven people=20 >>care enough to even comment, I'm not sure we have a mandate for this. >> >>So, if there is anyone out there who cares but has not said=20 >>so, please=20 >>do so soon. >> >>Aki Niemi wrote: >> >> >>>I'll have to vote for no/no. I don't think it solves the=20 >> >>real problem, >> >>>which is not having the sender/recipient ability to abort transfer >>>mid-message. >>> >>>Cheers, >>>Aki >>> >>>On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: >>> >>> >>>>I'd like to try and get some closure on this: >>>> >>>>Please answer yes or no to the following: >>>> >>>>1) Should we add the optional signaling of the maximum=20 >> >>content size you=20 >> >>>>are willing to _receive_ into the SDP exchange. >>>> >>>>2) Should we add the optional signaling of the maximum=20 >> >>content size you=20 >> >>>>are planning to _send_ into the SDP exchange. >>>> >>>>3) If either 1 or 2 is yes, do we send one value for the=20 >> >>session, or one=20 >> >>>>value per each type for which we have indicated support. >>>> >>>>My personal opinions: >>>> >>>>No and No. In all honesty, I think this could be a useful=20 >> >>feature, but I=20 >> >>>>don't think MSRP has to have it to function. I am voting=20 >> >>no, not because=20 >> >>>>I disagree with the feature, but because I don't want to=20 >> >>add additional=20 >> >>>>work to completing MSRP unless it is absolutely necessary. But if=20 >>>>consensus says we need it, I do not object on any technical basis. >>>> >>>> >>>> >>>> >>>>Chris Boulton wrote: >>>> >>>> >>>> >>>>>I think this feature would certainly be useful for max=20 >> >>receive (if it was type specific) BUT I am not convinced about send. >> >>>>>Chris. >>>>> >>>>> >>>>> -----Original Message-----=20 >>>>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 >>>>> Sent: Tue 25/05/2004 18:27=20 >>>>> To: Christer Holmberg (JO/LMF)=20 >>>>> Cc: hisham.khartabil@nokia.com; simple@ietf.org=20 >>>>> Subject: Re: [Simple] Re: MSRP: Max message size indication >>>>>=09 >>>>>=09 >>>>> >>>>> Let me step up a level: >>>>>=09 >>>>> By the required vs useful discussion, I was referring=20 >> >>to the feature of >> >>>>> being able to signal size limitations itself, rather=20 >> >>than some aspect of >> >>>>> the feature. >>>>>=09 >>>>> So, what do others about whether the feature of being=20 >> >>able to signal >> >>>>> message size limits is required? >>>>>=09 >>>>> Christer Holmberg (JO/LMF) wrote: >>>>>=09 >>>>> > Hi, >>>>> > >>>>> > >>>>> >>(Ignore my yet-another-empty reply. This time I blame=20 >> >>the combined >> >>>>> >>ergonomics of Thunderbird and my laptop.) >>>>> >> >>>>> >>That brings up an interesting meta-question. What is the bar >>>>> >>for putting new features into MSRP at this stage? Is=20 >> >>"useful" enough? Or >> >>>>> >>should we limit new features to things that we decide=20 >> >>are "required." >> >>>>> > >>>>> > >>>>> > Well, the max-receive is required, and I think it is=20 >> >>very useful. As I wrote earlier, the question is if it should=20 >>be possible to indicate separate values for different media types. >> >>>>> > >>>>> > The max-send is not required, but I still think it=20 >> >>would be very useful. Earlier I gave some examples I think=20 >>are very valid (nodes may try to reserve memory according to=20 >>how much big messages then can expect to receive,=20 >>redirection/forking may be done based on the information etc=20 >>etc etc). It wouldn't have any impacts on the protocol=20 >>functionality itself, and there would be no interop problems=20 >>with nodes that don't understand the max-send=20 >>attribute/parameter (or just don't care about it). >> >>>>> > >>>>> > Regards, >>>>> > >>>>> > Christer Holmberg >>>>> > Ericsson Finland >>>>> > >>>>> > >>>>> > >>>>> >>hisham.khartabil@nokia.com wrote: >>>>> >> >>>>> >> >>>>> >>>I think max-receive is useful, but not max-send. >>>>> >>> >>>>> >>>/Hisham >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>>>-----Original Message----- >>>>> >>>>From: simple-bounces@ietf.org >>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>> >>>>Of ext Ben Campbell >>>>> >>>>Sent: 25.May.2004 17:49 >>>>> >>>>To: Christer Holmberg (JO/LMF) >>>>> >>>>Cc: 'simple@ietf.org' >>>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication >>>>> >>>> >>>>> >>>> >>>>> >>>>(Oops, itchy trigger finger--ignore my last mail on=20 >> >>the subject.) >> >>>>> >>>> >>>>> >>>>I do not have strong feelings on this as a=20 >> >>requirement. If we >> >>>>> >>>>do want to >>>>> >>>>do it, the general approach seems good at the first=20 >> >>read, anyway. I >> >>>>> >>>>don't think there is a need for the non-type specific size >>>>> >> >>>>> >>attribute. >>>>> >> >>>>> >>>>The only advantage would be to reduce size of the SDP. I >>>>> >>>>don't see that >>>>> >>>>as a big requirement, since it normally only happens one >>>>> >> >>>>> >>per session. >>>>> >> >>>>> >>>>Do others have thoughts on the matter? Do we need this >>>>> >> >>>>> >>feature at all? >>>>> >> >>>>> >>>> >>>>> >>>> >>>>> >>>>Christer Holmberg (JO/LMF) wrote: >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>>>Hi, >>>>> >>>>> >>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I >>>>> >>>> >>>>> >>>>am bringing to the list the issue about being able to >>>>> >>>>indicate the max content size a node is able to receive. >>>>> >>>>Also, as input, in chapter 4 of >>>>>=09 >>>>> >>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is >>>>> >>>>> >>>>a requirement for such functionality: >>>>> >>>> >>>>> >>>> >>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum >>>>> >>>> >>>>> >>>>message size it is willing to receive. >>>>> >>>> >>>>> >>>> >>>>> >>>>>I think it would be useful if clients could indicate the >>>>> >>>> >>>>> >>>>maximum payload size he is able to receive, and also send, >>>>> >>>>either per type or stream. Note that I am talking about the >>>>> >>>>total message/content size, not the size of individual >>>>> >>>>fragments (the spec does say that messages bigger than 2k >>>>> >>>>should be fragmented). >>>>> >>>> >>>>> >>>> >>>>> >>>>>If the max size is dependent on the media type, max size >>>>> >>>> >>>>> >>>>could be defined as a accept-type token paramter: >>>>> >>>> >>>>> >>>> >>>>> >>>>>example: >>>>> >>>>> >>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, >>>>> >>>> >>>>> >>>>Y;max-send=3D2000;max-receive=3D500 >>>>> >>>> >>>>> >>>> >>>>> >>>>>And, if the message size it not type dependent, generic max >>>>> >>>> >>>>> >>>>size attributes could be used. >>>>> >>>> >>>>> >>>> >>>>> >>>>>example: >>>>> >>>>> >>>>> >>>>>a=3Dmax-send: 1000 >>>>> >>>>>a=3Dmax-receive:1000 >>>>> >>>>> >>>>> >>>>>Even if one is not going to send more than the other party >>>>> >>>> >>>>> >>>>indicates he is able to receive I still think it is=20 >> >>important >> >>>>> >>>>that a node can indicate how much he is able to send. For >>>>> >>>>example, the remote node may reserve memory=20 >> >>according to that >> >>>>> >>>>information, and/or intermediate proxies may do >>>>> >>>>forking/routing based on the client capabilities. >>>>> >>>> >>>>> >>>> >>>>> >>>>>An MSRP "message size too big" error code could also be >>>>> >>>> >>>>> >>>>useful, if a node for whatever reason is not able=20 >> >>to accept a >> >>>>> >>>>SEND message. This may be due to that the remote node is >>>>> >>>>sending more data than was agreed in the offer/answer, but >>>>> >>>>also due to that the receiving node for a short period isn't >>>>> >>>>able to receive the agreed data size (if the max size change >>>>> >>>>is permanent a new offer should of course be sent,=20 >> >>instead of >> >>>>> >>>>sending an error reply to every SEND). At the=20 >> >>interim meeting >> >>>>> >>>>is was desired to have a mechanism to "interrupt" the >>>>> >>>>receival of a message, and this error code could be used to >>>>> >>>>indicate that. The sender would then stop sending the >>>>> >>>>message, and any possible yet unsent fragments. >>>>> >>>> >>>>> >>>> >>>>> >>>>>Regards, >>>>> >>>>> >>>>> >>>>>Christer Holmberg >>>>> >>>>>Ericsson Finland >>>>> >>>> >>>>> >>>> >>>>> >>>>_______________________________________________ >>>>> >>>>Simple mailing list >>>>> >>>>Simple@ietf.org >>>>> >>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>>> >> >>>>>=09 >>>>>=09 >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>=09 >>>>> >>>>> >>>>> >>>>>This message has been scanned for viruses by MailControl -=20 >=20 > www.mailcontrol.com >=20 >>>> >>>> >>>>---------------------------------------------------------------------= --- >>>> >>>>_______________________________________________ >>>>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-bounces@ietf.org Tue Jun 8 17:55:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26526 for ; Tue, 8 Jun 2004 17:55:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoZ9-00063S-5v for simple-archive@ietf.org; Tue, 08 Jun 2004 17:55:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoTU-00039h-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 17:49:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXoQ0-0001CQ-02; Tue, 08 Jun 2004 17:46:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXoID-0000Bk-Mc; Tue, 08 Jun 2004 17:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXntE-00041X-H0; Tue, 08 Jun 2004 17:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXmJ3-0003HH-0f for simple@megatron.ietf.org; Tue, 08 Jun 2004 15:30: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 PAA19004 for ; Tue, 8 Jun 2004 15:30:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXmJ1-0005ZL-Ms for simple@ietf.org; Tue, 08 Jun 2004 15:30:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXmI8-0004jS-00 for simple@ietf.org; Tue, 08 Jun 2004 15:29:48 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BXmH9-00033Q-00 for simple@ietf.org; Tue, 08 Jun 2004 15:28:47 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i58JS5Lc010945; Tue, 8 Jun 2004 14:28:05 -0500 (CDT) Received: from ericsson.com (rvi2-93-145.sw.ericsson.se [153.88.93.145]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB84L0A; Tue, 8 Jun 2004 14:27:36 -0500 Message-ID: <40C61341.2080106@ericsson.com> Date: Tue, 08 Jun 2004 22:28:01 +0300 X-Sybari-Trust: f9726a12 100f6658 c3a3caf7 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: Ben Campbell Subject: Re: [Simple] Re: MSRP: Max message size indication References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> <40C489F9.1010706@dynamicsoft.com> <1086712308.6399.3551.camel@esdhcp09nok08184.ntc.nokia.com> <40C5FB62.9020204@dynamicsoft.com> <40C60FDF.4070009@ericsson.com> <40C611AD.9060109@dynamicsoft.com> In-Reply-To: <40C611AD.9060109@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosemberg , hisham.khartabil@nokia.com, Aki Niemi , "Christer Holmberg \(JO/LMF\)" , Chris Boulton , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, > Since we have a written requirement, I propose we move forward with "max > I am willing to receive" part, but not "the max I intend to send" part. Given that what you are proposing is the simplest way to meet the requirement (i.e., the proposal complays with the KISS rule), I agree that this is the way forward. Thanks, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 17:56:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26618 for ; Tue, 8 Jun 2004 17:56:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoZf-0006Mg-0I for simple-archive@ietf.org; Tue, 08 Jun 2004 17:56:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoTs-0003Fd-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 17:50:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXoQ2-0001CR-01; Tue, 08 Jun 2004 17:46:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXoHN-0008Vo-IP; Tue, 08 Jun 2004 17:37:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXntC-00040t-RS; Tue, 08 Jun 2004 17:12:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXmCP-0001PW-6A for simple@megatron.ietf.org; Tue, 08 Jun 2004 15:23: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 PAA18399 for ; Tue, 8 Jun 2004 15:23:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXmCN-0007LW-Te for simple@ietf.org; Tue, 08 Jun 2004 15:23:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXmBU-0006WV-00 for simple@ietf.org; Tue, 08 Jun 2004 15:22:57 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXmAe-0005Rz-00 for simple@ietf.org; Tue, 08 Jun 2004 15:22:04 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i58JLRLp027146; Tue, 8 Jun 2004 14:21:28 -0500 Message-ID: <40C611AD.9060109@dynamicsoft.com> Date: Tue, 08 Jun 2004 14:21:17 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Simple] Re: MSRP: Max message size indication References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> <40C489F9.1010706@dynamicsoft.com> <1086712308.6399.3551.camel@esdhcp09nok08184.ntc.nokia.com> <40C5FB62.9020204@dynamicsoft.com> <40C60FDF.4070009@ericsson.com> In-Reply-To: <40C60FDF.4070009@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosemberg , hisham.khartabil@nokia.com, Aki Niemi , "Christer Holmberg \(JO/LMF\)" , Chris Boulton , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Ben, > > let me try to understand the discussion here. We have a requirements > document (written by Jonathan) that says the following: > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-messaging-requirements-01.txt > > > "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message > size it is willing to receive." > > According to the requirements, the protocol MUST support it... do you > want to go through the requirements phase again at this point? Ah, I missed making that connection. Avoiding the question of which came first (agreed upon MSRP requirements and that document) for the moment, this would seem to support the yes/no vote. (That is, ability to express max you are willing to receive vs max you intend to send.) Since we have a written requirement, I propose we move forward with "max I am willing to receive" part, but not "the max I intend to send" part. > > Gonzalo > > > > Ben Campbell wrote: > >> So far, I have had 4 people (counting myself) respond no/no, 2 respond >> yes/yes, and one equivocation that I interpret as yes/no. >> >> This is a pretty small fraction of the work group. If only seven >> people care enough to even comment, I'm not sure we have a mandate for >> this. >> >> So, if there is anyone out there who cares but has not said so, please >> do so soon. >> >> Aki Niemi wrote: >> >>> I'll have to vote for no/no. I don't think it solves the real problem, >>> which is not having the sender/recipient ability to abort transfer >>> mid-message. >>> >>> Cheers, >>> Aki >>> >>> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: >>> >>>> I'd like to try and get some closure on this: >>>> >>>> Please answer yes or no to the following: >>>> >>>> 1) Should we add the optional signaling of the maximum content size >>>> you are willing to _receive_ into the SDP exchange. >>>> >>>> 2) Should we add the optional signaling of the maximum content size >>>> you are planning to _send_ into the SDP exchange. >>>> >>>> 3) If either 1 or 2 is yes, do we send one value for the session, or >>>> one value per each type for which we have indicated support. >>>> >>>> My personal opinions: >>>> >>>> No and No. In all honesty, I think this could be a useful feature, >>>> but I don't think MSRP has to have it to function. I am voting no, >>>> not because I disagree with the feature, but because I don't want to >>>> add additional work to completing MSRP unless it is absolutely >>>> necessary. But if consensus says we need it, I do not object on any >>>> technical basis. >>> >>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 17:56:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26709 for ; Tue, 8 Jun 2004 17:56:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoa9-0006Rg-98 for simple-archive@ietf.org; Tue, 08 Jun 2004 17:56:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoUG-0003Ln-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 17:50:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXoQ5-0001CR-00; Tue, 08 Jun 2004 17:46:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXoES-00084t-Ec; Tue, 08 Jun 2004 17:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXnt9-0003zu-Ah; Tue, 08 Jun 2004 17:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXm4d-000631-Lv for simple@megatron.ietf.org; Tue, 08 Jun 2004 15:15: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 PAA17810 for ; Tue, 8 Jun 2004 15:15:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXm4c-0000hr-D8 for simple@ietf.org; Tue, 08 Jun 2004 15:15:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXm3Y-0007h2-00 for simple@ietf.org; Tue, 08 Jun 2004 15:14:45 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BXm34-0006t2-00 for simple@ietf.org; Tue, 08 Jun 2004 15:14:14 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i58JDcLc006156; Tue, 8 Jun 2004 14:13:38 -0500 (CDT) Received: from ericsson.com (rvi2-93-145.sw.ericsson.se [153.88.93.145]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB84J84; Tue, 8 Jun 2004 14:13:10 -0500 Message-ID: <40C60FDF.4070009@ericsson.com> Date: Tue, 08 Jun 2004 22:13:35 +0300 X-Sybari-Trust: 0a79eaa5 100f6658 c3a3caf7 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: Ben Campbell Subject: Re: [Simple] Re: MSRP: Max message size indication References: <45730E094814E44488F789C1CDED27AE0219B2D1@gbnewp0758m.eu.ubiquity.net> <40C489F9.1010706@dynamicsoft.com> <1086712308.6399.3551.camel@esdhcp09nok08184.ntc.nokia.com> <40C5FB62.9020204@dynamicsoft.com> In-Reply-To: <40C5FB62.9020204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosemberg , hisham.khartabil@nokia.com, Aki Niemi , "Christer Holmberg \(JO/LMF\)" , Chris Boulton , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, let me try to understand the discussion here. We have a requirements document (written by Jonathan) that says the following: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-messaging-requirements-01.txt "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message size it is willing to receive." According to the requirements, the protocol MUST support it... do you want to go through the requirements phase again at this point? Gonzalo Ben Campbell wrote: > So far, I have had 4 people (counting myself) respond no/no, 2 respond > yes/yes, and one equivocation that I interpret as yes/no. > > This is a pretty small fraction of the work group. If only seven people > care enough to even comment, I'm not sure we have a mandate for this. > > So, if there is anyone out there who cares but has not said so, please > do so soon. > > Aki Niemi wrote: > >> I'll have to vote for no/no. I don't think it solves the real problem, >> which is not having the sender/recipient ability to abort transfer >> mid-message. >> >> Cheers, >> Aki >> >> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: >> >>> I'd like to try and get some closure on this: >>> >>> Please answer yes or no to the following: >>> >>> 1) Should we add the optional signaling of the maximum content size >>> you are willing to _receive_ into the SDP exchange. >>> >>> 2) Should we add the optional signaling of the maximum content size >>> you are planning to _send_ into the SDP exchange. >>> >>> 3) If either 1 or 2 is yes, do we send one value for the session, or >>> one value per each type for which we have indicated support. >>> >>> My personal opinions: >>> >>> No and No. In all honesty, I think this could be a useful feature, >>> but I don't think MSRP has to have it to function. I am voting no, >>> not because I disagree with the feature, but because I don't want to >>> add additional work to completing MSRP unless it is absolutely >>> necessary. But if consensus says we need it, I do not object on any >>> technical basis. >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 17:57:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26811 for ; Tue, 8 Jun 2004 17:57:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoae-0006Xs-Dn for simple-archive@ietf.org; Tue, 08 Jun 2004 17:57:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoUh-0003SX-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 17:50:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXoQ8-0001CQ-01; Tue, 08 Jun 2004 17:46:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXoBd-0007fH-M3; Tue, 08 Jun 2004 17:31:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXnsz-0003ro-Rg; Tue, 08 Jun 2004 17:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXlsE-0005dA-Ke for simple@megatron.ietf.org; Tue, 08 Jun 2004 15:03: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 PAA16295 for ; Tue, 8 Jun 2004 15:03:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXlsD-0005PV-Et for simple@ietf.org; Tue, 08 Jun 2004 15:03:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXlrE-0004Y3-00 for simple@ietf.org; Tue, 08 Jun 2004 15:02:01 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BXlqM-0003gz-00 for simple@ietf.org; Tue, 08 Jun 2004 15:01:06 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58J15PA007453 for ; Tue, 8 Jun 2004 21:01:05 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 21:01:05 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 21:01:05 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'simple@ietf.org'" Date: Tue, 8 Jun 2004 21:00:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 08 Jun 2004 19:01:05.0710 (UTC) FILETIME=[F35E84E0:01C44D8A] Subject: [Simple] MSRP: Rejecting a message which can't fully be received X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I would like to start a separate discussion about the issue of rejecting a MSRP message, if a node for whatever reason is not able to handle the whole message, to keep it separate from the discussion about the max-size attribute. One scenario, as we've seen in the discussion about the max-size attribute, when a message is too big for a node to handle. It has been proposed that it should be possible to send a 4xx response, even before a MSRP message has been fully received, and eg Adam said it should be possible. So, I would suggest that we go from there. Then, the question is what information could be included in the response. In fact, there is a requirement (REQ-CONTENT-2) saying "A 413 response MUST be capable of indicating the maximum allowed message size." which could be used (assuming the requirement is valid for session based messaging) for the case when the message is too big. However, there may also be other scenarios, and I guess we would need to identify them. Hisham gave an example where the actual message itself is not too big, but due to previously received messages there is simply no room for it. Should we have some kind of "retry-after" indication for this case? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 19:01:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05314 for ; Tue, 8 Jun 2004 19:01:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXpb7-00031F-49 for simple-archive@ietf.org; Tue, 08 Jun 2004 19:01:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXpPJ-00074o-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 18:49:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXpEM-0003cz-00; Tue, 08 Jun 2004 18:38:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXp9R-0000Rj-Cs; Tue, 08 Jun 2004 18:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXnu5-0004TH-Hn; Tue, 08 Jun 2004 17:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXneK-0008Dj-UL for simple@megatron.ietf.org; Tue, 08 Jun 2004 16:56: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 QAA23524 for ; Tue, 8 Jun 2004 16:56:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXneJ-0001HB-Cg for simple@ietf.org; Tue, 08 Jun 2004 16:56:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXndK-0000QL-00 for simple@ietf.org; Tue, 08 Jun 2004 16:55:46 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BXnbw-0006SN-00 for simple@ietf.org; Tue, 08 Jun 2004 16:54:20 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i58KrmLp027405; Tue, 8 Jun 2004 15:53:49 -0500 Message-ID: <40C62755.5020305@dynamicsoft.com> Date: Tue, 08 Jun 2004 15:53:41 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" Subject: [Simple] Re: MSRP: Ending a session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: > Hi, > > Chapter 6.5.4 in the MSRP draft (version -06) says: > > "When either endpoint in an MSRP session wishes to end the session, it > first signals its intent using the normal processing for the > signaling protocol. For example, in SIP, it would send a BYE request > to the peer. After agreeing to end the session, the host endpoint > MUST release any resources acquired as part of the session." > > Later in the chapter it is also described how possible outstanding MSRP transactions > are handled when a session is to be released. > > Now, I don't think it should be a must for a node to wait for a node to receive the BYE response before the TCP resources are released. Many nodes releases the media resources at the same time as the BYE is sent. And, even if would keep the connection open for possible outstanding MSRP transactions they would most likely be "lost" anyway, since a user will not (in gateway scenarios may not even be able to) wait for possible messages after the release message is sent. The intent was not that you must wait until that point, but that you must eventually release the resources. I agree it could be worded a little better. > > Also, chapter 15.1.1 in RFC3261 says: > > "Once the BYE is constructed, the UAC core creates a new non-INVITE > client transaction, and passes it the BYE request. The UAC MUST > consider the session terminated (and therefore stop sending or > listening for media) as soon as the BYE request is passed to the > client transaction." > > To me this clearly indicates that a node does not need to keep resources and wait for anything after the BYE is sent. > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 8 19:01:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05397 for ; Tue, 8 Jun 2004 19:01:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXpbO-00034K-Ne for simple-archive@ietf.org; Tue, 08 Jun 2004 19:01:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXpPj-0007Bb-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 18:49:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXpEO-0003c6-00; Tue, 08 Jun 2004 18:38:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXp77-0008Uw-EI; Tue, 08 Jun 2004 18:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXntz-0004On-0p; Tue, 08 Jun 2004 17:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXnK2-0003f3-RG for simple@megatron.ietf.org; Tue, 08 Jun 2004 16:35: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 QAA22344 for ; Tue, 8 Jun 2004 16:35:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXnK1-0006Rj-7E for simple@ietf.org; Tue, 08 Jun 2004 16:35:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXnIz-0005aS-00 for simple@ietf.org; Tue, 08 Jun 2004 16:34:46 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BXnHz-0004i0-00 for simple@ietf.org; Tue, 08 Jun 2004 16:33:43 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i58KXhPA014707 for ; Tue, 8 Jun 2004 22:33:43 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 22:33:43 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 22:33:43 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Ben Campbell'" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 22:33:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jun 2004 20:33:43.0750 (UTC) FILETIME=[E4381E60:01C44D97] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, >I just replied to a similar comment from Gonzalo. I had=20 >forgotten about that requirement in the draft. That requirement seems = to me=20 >to require being able to indicate the max size you are willing to=20 >receive. It does not seem to require indicating the max size you = intend to send. That is correct. I did mention the requirement a long time ago (I = copy/pasted the requirement text in a post, as Gonzalo also did), and = have referred to it a few times since then. But, there has been so many = posts, and there are also a number of other issues, so I understand = that information may get lossed :) And, as you also said (and which I think I've also said before), the = requirement is for indicating the max size you intend to receive only. = There is no written requirement to indicate the max size you intend to = send. That is something I've proposed to add since I think the = information could be useful. Regards, Christer Holmberg Ericsson Finland >=20 > Christer Holmberg (JO/LMF) wrote: >=20 > > Hi Ben, > >=20 > > If for no other reason (ie if nobody thinks the usage=20 > examples I've given are valid), I think the requirement=20 > (REQ-CONTENT-1) is the "mandate" we need. Or, have I=20 > missunderstood the requirment? Of course the meaning of the=20 > requirement could be that one should be able to indicate the=20 > size in an error response, but the text about offer/answer,=20 > and that negotiation is needed , at least to me sounds that=20 > negotiation is what it's really about. > >=20 > > Now, of course, if there are technical reasons and/or big=20 > problems why a requirement can not be fullfilled we need to=20 > re-visit the requirments, and possibly change/remove=20 > something. But, so far most of the comments have been about=20 > that fact that this doesn't solve the issue when messages=20 > need to be rejected. However, the max-size attribute is not=20 > supposed to solve that issue, and the requirment says nothing=20 > about that issue, so I don't see why we should remove a=20 > requirement just because it doesn't solve something it's not=20 > even supposed to solve... > >=20 > > If we remove requirements just becuase we suddenly don't=20 > think they are needed I wonder how much work we have put on=20 > the requirements in the first place, especially when we have=20 > came this far with the actual protocol.=20 > >=20 > > HOWEVER, I would really not like to use the requirements as=20 > an argument, and I really hope we all think we have stable=20 > requirements - instead I have tried to describe the technical=20 > reasons why I think this would be useful. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: 8. kes=E4kuuta 2004 20:46 > >>To: Aki Niemi > >>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > >>simple@ietf.org; Christer > >>Holmberg (JO/LMF) > >>Subject: Re: [Simple] Re: MSRP: Max message size indication > >> > >> > >>So far, I have had 4 people (counting myself) respond no/no,=20 > >>2 respond=20 > >>yes/yes, and one equivocation that I interpret as yes/no. > >> > >>This is a pretty small fraction of the work group. If only=20 > >>seven people=20 > >>care enough to even comment, I'm not sure we have a mandate=20 > for this. > >> > >>So, if there is anyone out there who cares but has not said=20 > >>so, please=20 > >>do so soon. > >> > >>Aki Niemi wrote: > >> > >> > >>>I'll have to vote for no/no. I don't think it solves the=20 > >> > >>real problem, > >> > >>>which is not having the sender/recipient ability to abort transfer > >>>mid-message. > >>> > >>>Cheers, > >>>Aki > >>> > >>>On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > >>> > >>> > >>>>I'd like to try and get some closure on this: > >>>> > >>>>Please answer yes or no to the following: > >>>> > >>>>1) Should we add the optional signaling of the maximum=20 > >> > >>content size you=20 > >> > >>>>are willing to _receive_ into the SDP exchange. > >>>> > >>>>2) Should we add the optional signaling of the maximum=20 > >> > >>content size you=20 > >> > >>>>are planning to _send_ into the SDP exchange. > >>>> > >>>>3) If either 1 or 2 is yes, do we send one value for the=20 > >> > >>session, or one=20 > >> > >>>>value per each type for which we have indicated support. > >>>> > >>>>My personal opinions: > >>>> > >>>>No and No. In all honesty, I think this could be a useful=20 > >> > >>feature, but I=20 > >> > >>>>don't think MSRP has to have it to function. I am voting=20 > >> > >>no, not because=20 > >> > >>>>I disagree with the feature, but because I don't want to=20 > >> > >>add additional=20 > >> > >>>>work to completing MSRP unless it is absolutely necessary. But if = > >>>>consensus says we need it, I do not object on any technical = basis. > >>>> > >>>> > >>>> > >>>> > >>>>Chris Boulton wrote: > >>>> > >>>> > >>>> > >>>>>I think this feature would certainly be useful for max=20 > >> > >>receive (if it was type specific) BUT I am not convinced about = send. > >> > >>>>>Chris. > >>>>> > >>>>> > >>>>> -----Original Message-----=20 > >>>>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > >>>>> Sent: Tue 25/05/2004 18:27=20 > >>>>> To: Christer Holmberg (JO/LMF)=20 > >>>>> Cc: hisham.khartabil@nokia.com; simple@ietf.org=20 > >>>>> Subject: Re: [Simple] Re: MSRP: Max message size indication > >>>>>=09 > >>>>>=09 > >>>>> > >>>>> Let me step up a level: > >>>>>=09 > >>>>> By the required vs useful discussion, I was referring=20 > >> > >>to the feature of > >> > >>>>> being able to signal size limitations itself, rather=20 > >> > >>than some aspect of > >> > >>>>> the feature. > >>>>>=09 > >>>>> So, what do others about whether the feature of being=20 > >> > >>able to signal > >> > >>>>> message size limits is required? > >>>>>=09 > >>>>> Christer Holmberg (JO/LMF) wrote: > >>>>>=09 > >>>>> > Hi, > >>>>> > > >>>>> > > >>>>> >>(Ignore my yet-another-empty reply. This time I blame=20 > >> > >>the combined > >> > >>>>> >>ergonomics of Thunderbird and my laptop.) > >>>>> >> > >>>>> >>That brings up an interesting meta-question. What is the bar > >>>>> >>for putting new features into MSRP at this stage? Is=20 > >> > >>"useful" enough? Or > >> > >>>>> >>should we limit new features to things that we decide=20 > >> > >>are "required." > >> > >>>>> > > >>>>> > > >>>>> > Well, the max-receive is required, and I think it is=20 > >> > >>very useful. As I wrote earlier, the question is if it should=20 > >>be possible to indicate separate values for different media types. > >> > >>>>> > > >>>>> > The max-send is not required, but I still think it=20 > >> > >>would be very useful. Earlier I gave some examples I think=20 > >>are very valid (nodes may try to reserve memory according to=20 > >>how much big messages then can expect to receive,=20 > >>redirection/forking may be done based on the information etc=20 > >>etc etc). It wouldn't have any impacts on the protocol=20 > >>functionality itself, and there would be no interop problems=20 > >>with nodes that don't understand the max-send=20 > >>attribute/parameter (or just don't care about it). > >> > >>>>> > > >>>>> > Regards, > >>>>> > > >>>>> > Christer Holmberg > >>>>> > Ericsson Finland > >>>>> > > >>>>> > > >>>>> > > >>>>> >>hisham.khartabil@nokia.com wrote: > >>>>> >> > >>>>> >> > >>>>> >>>I think max-receive is useful, but not max-send. > >>>>> >>> > >>>>> >>>/Hisham > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>>>-----Original Message----- > >>>>> >>>>From: simple-bounces@ietf.org > >>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>>>> >>>>Of ext Ben Campbell > >>>>> >>>>Sent: 25.May.2004 17:49 > >>>>> >>>>To: Christer Holmberg (JO/LMF) > >>>>> >>>>Cc: 'simple@ietf.org' > >>>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>(Oops, itchy trigger finger--ignore my last mail on=20 > >> > >>the subject.) > >> > >>>>> >>>> > >>>>> >>>>I do not have strong feelings on this as a=20 > >> > >>requirement. If we > >> > >>>>> >>>>do want to > >>>>> >>>>do it, the general approach seems good at the first=20 > >> > >>read, anyway. I > >> > >>>>> >>>>don't think there is a need for the non-type specific size > >>>>> >> > >>>>> >>attribute. > >>>>> >> > >>>>> >>>>The only advantage would be to reduce size of the SDP. I > >>>>> >>>>don't see that > >>>>> >>>>as a big requirement, since it normally only happens one > >>>>> >> > >>>>> >>per session. > >>>>> >> > >>>>> >>>>Do others have thoughts on the matter? Do we need this > >>>>> >> > >>>>> >>feature at all? > >>>>> >> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>Christer Holmberg (JO/LMF) wrote: > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>Hi, > >>>>> >>>>> > >>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > >>>>> >>>> > >>>>> >>>>am bringing to the list the issue about being able to > >>>>> >>>>indicate the max content size a node is able to receive. > >>>>> >>>>Also, as input, in chapter 4 of > >>>>>=09 > >>>>> > >>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >>>>> > >>>>> >>>>a requirement for such functionality: > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >>>>> >>>> > >>>>> >>>>message size it is willing to receive. > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>I think it would be useful if clients could indicate the > >>>>> >>>> > >>>>> >>>>maximum payload size he is able to receive, and also send, > >>>>> >>>>either per type or stream. Note that I am talking about the > >>>>> >>>>total message/content size, not the size of individual > >>>>> >>>>fragments (the spec does say that messages bigger than 2k > >>>>> >>>>should be fragmented). > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>If the max size is dependent on the media type, max size > >>>>> >>>> > >>>>> >>>>could be defined as a accept-type token paramter: > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>example: > >>>>> >>>>> > >>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >>>>> >>>> > >>>>> >>>>Y;max-send=3D2000;max-receive=3D500 > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>And, if the message size it not type dependent, generic = max > >>>>> >>>> > >>>>> >>>>size attributes could be used. > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>example: > >>>>> >>>>> > >>>>> >>>>>a=3Dmax-send: 1000 > >>>>> >>>>>a=3Dmax-receive:1000 > >>>>> >>>>> > >>>>> >>>>>Even if one is not going to send more than the other party > >>>>> >>>> > >>>>> >>>>indicates he is able to receive I still think it is=20 > >> > >>important > >> > >>>>> >>>>that a node can indicate how much he is able to send. For > >>>>> >>>>example, the remote node may reserve memory=20 > >> > >>according to that > >> > >>>>> >>>>information, and/or intermediate proxies may do > >>>>> >>>>forking/routing based on the client capabilities. > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>An MSRP "message size too big" error code could also be > >>>>> >>>> > >>>>> >>>>useful, if a node for whatever reason is not able=20 > >> > >>to accept a > >> > >>>>> >>>>SEND message. This may be due to that the remote node is > >>>>> >>>>sending more data than was agreed in the offer/answer, but > >>>>> >>>>also due to that the receiving node for a short period = isn't > >>>>> >>>>able to receive the agreed data size (if the max size = change > >>>>> >>>>is permanent a new offer should of course be sent,=20 > >> > >>instead of > >> > >>>>> >>>>sending an error reply to every SEND). At the=20 > >> > >>interim meeting > >> > >>>>> >>>>is was desired to have a mechanism to "interrupt" the > >>>>> >>>>receival of a message, and this error code could be used to > >>>>> >>>>indicate that. The sender would then stop sending the > >>>>> >>>>message, and any possible yet unsent fragments. > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>>Regards, > >>>>> >>>>> > >>>>> >>>>>Christer Holmberg > >>>>> >>>>>Ericsson Finland > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>_______________________________________________ > >>>>> >>>>Simple mailing list > >>>>> >>>>Simple@ietf.org > >>>>> >>>>https://www1.ietf.org/mailman/listinfo/simple > >>>>> >>>> > >>>>> >> > >>>>>=09 > >>>>>=09 > >>>>> _______________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>>=09 > >>>>> > >>>>> > >>>>> > >>>>>This message has been scanned for viruses by MailControl -=20 > >=20 > > www.mailcontrol.com > >=20 > >>>> > >>>> > >>>>---------------------------------------------------------- > -------------- > >>>> > >>>>_______________________________________________ > >>>>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-bounces@ietf.org Tue Jun 8 19:52:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10729 for ; Tue, 8 Jun 2004 19:52:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXqOf-0001lZ-S1 for simple-archive@ietf.org; Tue, 08 Jun 2004 19:52:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXqJU-0006iG-00 for simple-archive@ietf.org; Tue, 08 Jun 2004 19:47:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXqHH-0005RN-04; Tue, 08 Jun 2004 19:45:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXq2C-0001LP-3w; Tue, 08 Jun 2004 19:29:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXpoI-000329-Db; Tue, 08 Jun 2004 19:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXpg6-0007cc-U6 for simple@megatron.ietf.org; Tue, 08 Jun 2004 19:06: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 TAA06410 for ; Tue, 8 Jun 2004 19:06:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXpg4-0003jK-Qb for simple@ietf.org; Tue, 08 Jun 2004 19:06:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXpVY-0000cg-00 for simple@ietf.org; Tue, 08 Jun 2004 18:55:54 -0400 Received: from c24375.rim.net ([216.9.243.75] helo=mhs98ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1BXpGq-0004Qw-00 for simple@ietf.org; Tue, 08 Jun 2004 18:40:41 -0400 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs98ykf.rim.net (Postfix) with SMTP id 2322FB692B for ; Tue, 8 Jun 2004 18:39:55 -0400 (EDT) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2004060818395403242 ; Tue, 08 Jun 2004 18:39:54 -0400 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jun 2004 18:39:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Re: MSRP: Max message size indication Date: Tue, 8 Jun 2004 18:39:52 -0400 Message-ID: Thread-Topic: [Simple] Re: MSRP: Max message size indication Thread-Index: AcRNhEEM0Jg2s7rFTBqn75ZncHuRIAAJK+9w From: "Andrew Allen" To: "Ben Campbell" , "Aki Niemi" X-OriginalArrivalTime: 08 Jun 2004 22:39:54.0200 (UTC) FILETIME=[848F1D80:01C44DA9] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ben, Please count me in the Yes/No column. I think for now to comply with KISS I think we should just do it as a global receive max-size and not per type.=20 Andrew > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Tuesday, June 08, 2004 1:46 PM > To: Aki Niemi > Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org; Christer > Holmberg (JO/LMF) > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 > So far, I have had 4 people (counting myself) respond no/no, 2 respond > yes/yes, and one equivocation that I interpret as yes/no. >=20 > This is a pretty small fraction of the work group. If only seven people > care enough to even comment, I'm not sure we have a mandate for this. >=20 > So, if there is anyone out there who cares but has not said so, please > do so soon. >=20 > Aki Niemi wrote: >=20 > > I'll have to vote for no/no. I don't think it solves the real problem, > > which is not having the sender/recipient ability to abort transfer > > mid-message. > > > > Cheers, > > Aki > > > > On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > > > >>I'd like to try and get some closure on this: > >> > >>Please answer yes or no to the following: > >> > >>1) Should we add the optional signaling of the maximum content size you > >>are willing to _receive_ into the SDP exchange. > >> > >>2) Should we add the optional signaling of the maximum content size you > >>are planning to _send_ into the SDP exchange. > >> > >>3) If either 1 or 2 is yes, do we send one value for the session, or one > >>value per each type for which we have indicated support. > >> > >>My personal opinions: > >> > >>No and No. In all honesty, I think this could be a useful feature, but I > >>don't think MSRP has to have it to function. I am voting no, not because > >>I disagree with the feature, but because I don't want to add additional > >>work to completing MSRP unless it is absolutely necessary. But if > >>consensus says we need it, I do not object on any technical basis. > >> > >> > >> > >> > >>Chris Boulton wrote: > >> > >> > >>>I think this feature would certainly be useful for max receive (if it > was type specific) BUT I am not convinced about send. > >>> > >>>Chris. > >>> > >>> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: Tue 25/05/2004 18:27 > >>> To: Christer Holmberg (JO/LMF) > >>> Cc: hisham.khartabil@nokia.com; simple@ietf.org > >>> Subject: Re: [Simple] Re: MSRP: Max message size indication > >>> > >>> > >>> > >>> Let me step up a level: > >>> > >>> By the required vs useful discussion, I was referring to the feature > of > >>> being able to signal size limitations itself, rather than some > aspect of > >>> the feature. > >>> > >>> So, what do others about whether the feature of being able to signal > >>> message size limits is required? > >>> > >>> Christer Holmberg (JO/LMF) wrote: > >>> > >>> > Hi, > >>> > > >>> > > >>> >>(Ignore my yet-another-empty reply. This time I blame the combined > >>> >>ergonomics of Thunderbird and my laptop.) > >>> >> > >>> >>That brings up an interesting meta-question. What is the bar > >>> >>for putting new features into MSRP at this stage? Is "useful" > enough? Or > >>> >>should we limit new features to things that we decide are > "required." > >>> > > >>> > > >>> > Well, the max-receive is required, and I think it is very useful. > As I wrote earlier, the question is if it should be possible to indicate > separate values for different media types. > >>> > > >>> > The max-send is not required, but I still think it would be very > useful. Earlier I gave some examples I think are very valid (nodes may try > to reserve memory according to how much big messages then can expect to > receive, redirection/forking may be done based on the information etc etc > etc). It wouldn't have any impacts on the protocol functionality itself, > and there would be no interop problems with nodes that don't understand > the max-send attribute/parameter (or just don't care about it). > >>> > > >>> > Regards, > >>> > > >>> > Christer Holmberg > >>> > Ericsson Finland > >>> > > >>> > > >>> > > >>> >>hisham.khartabil@nokia.com wrote: > >>> >> > >>> >> > >>> >>>I think max-receive is useful, but not max-send. > >>> >>> > >>> >>>/Hisham > >>> >>> > >>> >>> > >>> >>> > >>> >>>>-----Original Message----- > >>> >>>>From: simple-bounces@ietf.org > >>> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>> >>>>Of ext Ben Campbell > >>> >>>>Sent: 25.May.2004 17:49 > >>> >>>>To: Christer Holmberg (JO/LMF) > >>> >>>>Cc: 'simple@ietf.org' > >>> >>>>Subject: [Simple] Re: MSRP: Max message size indication > >>> >>>> > >>> >>>> > >>> >>>>(Oops, itchy trigger finger--ignore my last mail on the > subject.) > >>> >>>> > >>> >>>>I do not have strong feelings on this as a requirement. If we > >>> >>>>do want to > >>> >>>>do it, the general approach seems good at the first read, > anyway. I > >>> >>>>don't think there is a need for the non-type specific size > >>> >> > >>> >>attribute. > >>> >> > >>> >>>>The only advantage would be to reduce size of the SDP. I > >>> >>>>don't see that > >>> >>>>as a big requirement, since it normally only happens one > >>> >> > >>> >>per session. > >>> >> > >>> >>>>Do others have thoughts on the matter? Do we need this > >>> >> > >>> >>feature at all? > >>> >> > >>> >>>> > >>> >>>> > >>> >>>>Christer Holmberg (JO/LMF) wrote: > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>>>Hi, > >>> >>>>> > >>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I > >>> >>>> > >>> >>>>am bringing to the list the issue about being able to > >>> >>>>indicate the max content size a node is able to receive. > >>> >>>>Also, as input, in chapter 4 of > >>> >>>>draft-rosenberg-simple-messaging-requirements-01.txt there is > >>> >>>>a requirement for such functionality: > >>> >>>> > >>> >>>> > >>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum > >>> >>>> > >>> >>>>message size it is willing to receive. > >>> >>>> > >>> >>>> > >>> >>>>>I think it would be useful if clients could indicate the > >>> >>>> > >>> >>>>maximum payload size he is able to receive, and also send, > >>> >>>>either per type or stream. Note that I am talking about the > >>> >>>>total message/content size, not the size of individual > >>> >>>>fragments (the spec does say that messages bigger than 2k > >>> >>>>should be fragmented). > >>> >>>> > >>> >>>> > >>> >>>>>If the max size is dependent on the media type, max size > >>> >>>> > >>> >>>>could be defined as a accept-type token paramter: > >>> >>>> > >>> >>>> > >>> >>>>>example: > >>> >>>>> > >>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >>> >>>> > >>> >>>>Y;max-send=3D2000;max-receive=3D500 > >>> >>>> > >>> >>>> > >>> >>>>>And, if the message size it not type dependent, generic max > >>> >>>> > >>> >>>>size attributes could be used. > >>> >>>> > >>> >>>> > >>> >>>>>example: > >>> >>>>> > >>> >>>>>a=3Dmax-send: 1000 > >>> >>>>>a=3Dmax-receive:1000 > >>> >>>>> > >>> >>>>>Even if one is not going to send more than the other party > >>> >>>> > >>> >>>>indicates he is able to receive I still think it is important > >>> >>>>that a node can indicate how much he is able to send. For > >>> >>>>example, the remote node may reserve memory according to that > >>> >>>>information, and/or intermediate proxies may do > >>> >>>>forking/routing based on the client capabilities. > >>> >>>> > >>> >>>> > >>> >>>>>An MSRP "message size too big" error code could also be > >>> >>>> > >>> >>>>useful, if a node for whatever reason is not able to accept a > >>> >>>>SEND message. This may be due to that the remote node is > >>> >>>>sending more data than was agreed in the offer/answer, but > >>> >>>>also due to that the receiving node for a short period isn't > >>> >>>>able to receive the agreed data size (if the max size change > >>> >>>>is permanent a new offer should of course be sent, instead of > >>> >>>>sending an error reply to every SEND). At the interim meeting > >>> >>>>is was desired to have a mechanism to "interrupt" the > >>> >>>>receival of a message, and this error code could be used to > >>> >>>>indicate that. The sender would then stop sending the > >>> >>>>message, and any possible yet unsent fragments. > >>> >>>> > >>> >>>> > >>> >>>>>Regards, > >>> >>>>> > >>> >>>>>Christer Holmberg > >>> >>>>>Ericsson Finland > >>> >>>> > >>> >>>> > >>> >>>>_______________________________________________ > >>> >>>>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 > >>> > >>> > >>> > >>> > >>>This message has been scanned for viruses by MailControl - > www.mailcontrol.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 >=20 >=20 > _______________________________________________ > 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-bounces@ietf.org Wed Jun 9 11:40:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22084 for ; Wed, 9 Jun 2004 11:40:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY5Bs-00032G-Au for simple-archive@ietf.org; Wed, 09 Jun 2004 11:40:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY59N-0001BL-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 11:38:01 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY58K-0000Gu-00; Wed, 09 Jun 2004 11:36:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY51o-0007WX-Pd; Wed, 09 Jun 2004 11:30:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4vJ-0007I2-Vl; Wed, 09 Jun 2004 11:23:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4Zu-0000cs-FI for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:01: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 LAA18645 for ; Wed, 9 Jun 2004 11:01:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY4Zt-0002m1-AN for simple@ietf.org; Wed, 09 Jun 2004 11:01:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY4XU-0001fH-00 for simple@ietf.org; Wed, 09 Jun 2004 10:58:52 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BY4Ve-0000m5-00 for simple@ietf.org; Wed, 09 Jun 2004 10:56:59 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59EuvJ25989 for ; Wed, 9 Jun 2004 17:56:57 +0300 (EET DST) X-Scanned: Wed, 9 Jun 2004 17:56:39 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i59EudFI029731 for ; Wed, 9 Jun 2004 17:56:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00j2GAnE; Wed, 09 Jun 2004 17:56:38 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59EuWH13566 for ; Wed, 9 Jun 2004 17:56:32 +0300 (EET DST) Received: from nokia.com ([172.21.40.178]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 17:56:23 +0300 Message-ID: <40C72516.8000203@nokia.com> Date: Wed, 09 Jun 2004 17:56:22 +0300 From: Miguel 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-es MIME-Version: 1.0 To: SIMPLE mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2004 14:56:23.0032 (UTC) FILETIME=[EE396780:01C44E31] Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP directory I-D X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi: I have just submitted an I-D that proposes a solution to get an XCAP directory of XML documents. While the draft is published, you can fetch a copy from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-xcap-directory-00.html http://people.nokia.net/~miguel/drafts/draft-garcia-simple-xcap-directory-00.txt This is related to a recent post we saw a few days ago where we got an indication that the requirement for an XCAP client to retrieve a directory of XML documents have been identified in the Open Mobile Alliance. Comments? - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 11:41:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22399 for ; Wed, 9 Jun 2004 11:41:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY5D9-0003xq-Oc for simple-archive@ietf.org; Wed, 09 Jun 2004 11:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY5B9-0002ur-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 11:39:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY58b-0000Y0-00; Wed, 09 Jun 2004 11:37:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY58c-0008Kc-Iv; Wed, 09 Jun 2004 11:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4ve-0007kP-LC; Wed, 09 Jun 2004 11:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4ct-0001dy-0j for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:04: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 KAA16347 for ; Wed, 9 Jun 2004 10:11:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY3ne-0003mF-TD for simple@ietf.org; Wed, 09 Jun 2004 10:11:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY3mp-0002xl-00 for simple@ietf.org; Wed, 09 Jun 2004 10:10:41 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BY3m7-00028E-00 for simple@ietf.org; Wed, 09 Jun 2004 10:09:55 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i59E9rPA018131 for ; Wed, 9 Jun 2004 16:09:53 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 16:09:53 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Jun 2004 16:08:48 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Jonathan Rosenberg'" , Ben Campbell Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Wed, 9 Jun 2004 16:08:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 09 Jun 2004 14:09:53.0551 (UTC) FILETIME=[6F9061F0:01C44E2B] Content-Transfer-Encoding: quoted-printable Cc: hisham.khartabil@nokia.com, Chris Boulton , Aki Niemi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Jonathan, >I havent been following this discussion entirely, but here is=20 >my input. >=20 >The requirement in the requirements document is strictly=20 >talking about indicating the maximum an endpoint is willing to = receive. The primary=20 >purpose of this is for devices like mobile handsets, which want to be=20 >able to tell a peer "hey, don't send a huge image, I don't=20 >want to pay for that". I think its better to indicate this during the = sdp=20 >exchange, rather than have the mobile cut off an incoming messages = once=20 >it reaches that limit. Exactly. That is also what I have said all the time. Regards, Christer Holmberg Ericsson Finland >=20 > -Jonathan R. >=20 > Ben Campbell wrote: >=20 > > I just replied to a similar comment from Gonzalo. I had=20 > forgotten about=20 > > that requirement in the draft. That requirement seems to me=20 > to require=20 > > being able to indicate the max size you are willing to=20 > receive. It does=20 > > not seem to require indicating the max size you intend to send. > >=20 > > Christer Holmberg (JO/LMF) wrote: > >=20 > >> Hi Ben, > >> > >> If for no other reason (ie if nobody thinks the usage=20 > examples I've=20 > >> given are valid), I think the requirement (REQ-CONTENT-1) is the=20 > >> "mandate" we need. Or, have I missunderstood the=20 > requirment? Of course=20 > >> the meaning of the requirement could be that one should be able to = > >> indicate the size in an error response, but the text about=20 > >> offer/answer, and that negotiation is needed , at least to=20 > me sounds=20 > >> that negotiation is what it's really about. > >> > >> Now, of course, if there are technical reasons and/or big=20 > problems why=20 > >> a requirement can not be fullfilled we need to re-visit the=20 > >> requirments, and possibly change/remove something. But, so=20 > far most of=20 > >> the comments have been about that fact that this doesn't solve the = > >> issue when messages need to be rejected. However, the max-size=20 > >> attribute is not supposed to solve that issue, and the=20 > requirment says=20 > >> nothing about that issue, so I don't see why we should remove a=20 > >> requirement just because it doesn't solve something it's not even=20 > >> supposed to solve... > >> > >> If we remove requirements just becuase we suddenly don't=20 > think they=20 > >> are needed I wonder how much work we have put on the=20 > requirements in=20 > >> the first place, especially when we have came this far=20 > with the actual=20 > >> protocol. > >> HOWEVER, I would really not like to use the requirements as an=20 > >> argument, and I really hope we all think we have stable=20 > requirements -=20 > >> instead I have tried to describe the technical reasons why I think = > >> this would be useful. > >> > >> Regards, > >> > >> Christer Holmberg > >> Ericsson Finland > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>> Sent: 8. kes=E4kuuta 2004 20:46 > >>> To: Aki Niemi > >>> Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 > simple@ietf.org; Christer > >>> Holmberg (JO/LMF) > >>> Subject: Re: [Simple] Re: MSRP: Max message size indication > >>> > >>> > >>> So far, I have had 4 people (counting myself) respond no/no, 2=20 > >>> respond yes/yes, and one equivocation that I interpret as yes/no. > >>> > >>> This is a pretty small fraction of the work group. If only seven=20 > >>> people care enough to even comment, I'm not sure we have=20 > a mandate=20 > >>> for this. > >>> > >>> So, if there is anyone out there who cares but has not said so,=20 > >>> please do so soon. > >>> > >>> Aki Niemi wrote: > >>> > >>> > >>>> I'll have to vote for no/no. I don't think it solves the=20 > >>> > >>> > >>> real problem, > >>> > >>>> which is not having the sender/recipient ability to > abort transfer > >>>> mid-message. > >>>> > >>>> Cheers, > >>>> Aki > >>>> > >>>> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > >>>> > >>>> > >>>>> I'd like to try and get some closure on this: > >>>>> > >>>>> Please answer yes or no to the following: > >>>>> > >>>>> 1) Should we add the optional signaling of the maximum=20 > >>> > >>> > >>> content size you > >>> > >>>>> are willing to _receive_ into the SDP exchange. > >>>>> > >>>>> 2) Should we add the optional signaling of the maximum=20 > >>> > >>> > >>> content size you > >>> > >>>>> are planning to _send_ into the SDP exchange. > >>>>> > >>>>> 3) If either 1 or 2 is yes, do we send one value for the=20 > >>> > >>> > >>> session, or one > >>> > >>>>> value per each type for which we have indicated support. > >>>>> > >>>>> My personal opinions: > >>>>> > >>>>> No and No. In all honesty, I think this could be a useful=20 > >>> > >>> > >>> feature, but I > >>> > >>>>> don't think MSRP has to have it to function. I am voting=20 > >>> > >>> > >>> no, not because > >>> > >>>>> I disagree with the feature, but because I don't want to=20 > >>> > >>> > >>> add additional > >>> > >>>>> work to completing MSRP unless it is absolutely=20 > necessary. But if=20 > >>>>> consensus says we need it, I do not object on any=20 > technical basis. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Chris Boulton wrote: > >>>>> > >>>>> > >>>>> > >>>>>> I think this feature would certainly be useful for max=20 > >>> > >>> > >>> receive (if it was type specific) BUT I am not convinced=20 > about send. > >>> > >>>>>> Chris. > >>>>>> > >>>>>> > >>>>>> -----Original Message----- From: Ben Campbell=20 > >>>>>> [mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 > 25/05/2004 18:27=20 > >>>>>> To: Christer Holmberg (JO/LMF) Cc:=20 > >>>>>> hisham.khartabil@nokia.com; simple@ietf.org Subject: Re:=20 > >>>>>> [Simple] Re: MSRP: Max message size indication > >>>>>> =20 > >>>>>> =20 > >>>>>> > >>>>>> Let me step up a level: > >>>>>> =20 > >>>>>> By the required vs useful discussion, I was referring=20 > >>> > >>> > >>> to the feature of > >>> > >>>>>> being able to signal size limitations itself, rather=20 > >>> > >>> > >>> than some aspect of > >>> > >>>>>> the feature. > >>>>>> =20 > >>>>>> So, what do others about whether the feature of being=20 > >>> > >>> > >>> able to signal > >>> > >>>>>> message size limits is required? > >>>>>> =20 > >>>>>> Christer Holmberg (JO/LMF) wrote: > >>>>>> =20 > >>>>>> > Hi, > >>>>>> > > >>>>>> > > >>>>>> >>(Ignore my yet-another-empty reply. This time I blame=20 > >>> > >>> > >>> the combined > >>> > >>>>>> >>ergonomics of Thunderbird and my laptop.) > >>>>>> >> > >>>>>> >>That brings up an interesting meta-question.=20 > What is the bar > >>>>>> >>for putting new features into MSRP at this stage? Is=20 > >>> > >>> > >>> "useful" enough? Or > >>> > >>>>>> >>should we limit new features to things that we decide=20 > >>> > >>> > >>> are "required." > >>> > >>>>>> > > >>>>>> > > >>>>>> > Well, the max-receive is required, and I think it is=20 > >>> > >>> > >>> very useful. As I wrote earlier, the question is if it should be=20 > >>> possible to indicate separate values for different media types. > >>> > >>>>>> > > >>>>>> > The max-send is not required, but I still think it=20 > >>> > >>> > >>> would be very useful. Earlier I gave some examples I=20 > think are very=20 > >>> valid (nodes may try to reserve memory according to how much big=20 > >>> messages then can expect to receive, redirection/forking=20 > may be done=20 > >>> based on the information etc etc etc). It wouldn't have=20 > any impacts=20 > >>> on the protocol functionality itself, and there would be=20 > no interop=20 > >>> problems with nodes that don't understand the max-send=20 > >>> attribute/parameter (or just don't care about it). > >>> > >>>>>> > > >>>>>> > Regards, > >>>>>> > > >>>>>> > Christer Holmberg > >>>>>> > Ericsson Finland > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> >>hisham.khartabil@nokia.com wrote: > >>>>>> >> > >>>>>> >> > >>>>>> >>>I think max-receive is useful, but not max-send. > >>>>>> >>> > >>>>>> >>>/Hisham > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>>-----Original Message----- > >>>>>> >>>>From: simple-bounces@ietf.org > >>>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>>>>> >>>>Of ext Ben Campbell > >>>>>> >>>>Sent: 25.May.2004 17:49 > >>>>>> >>>>To: Christer Holmberg (JO/LMF) > >>>>>> >>>>Cc: 'simple@ietf.org' > >>>>>> >>>>Subject: [Simple] Re: MSRP: Max message size = indication > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>(Oops, itchy trigger finger--ignore my last mail on=20 > >>> > >>> > >>> the subject.) > >>> > >>>>>> >>>> > >>>>>> >>>>I do not have strong feelings on this as a=20 > >>> > >>> > >>> requirement. If we > >>> > >>>>>> >>>>do want to > >>>>>> >>>>do it, the general approach seems good at the first=20 > >>> > >>> > >>> read, anyway. I > >>> > >>>>>> >>>>don't think there is a need for the non-type=20 > specific size > >>>>>> >> > >>>>>> >>attribute. > >>>>>> >> > >>>>>> >>>>The only advantage would be to reduce size of=20 > the SDP. I > >>>>>> >>>>don't see that > >>>>>> >>>>as a big requirement, since it normally only=20 > happens one > >>>>>> >> > >>>>>> >>per session. > >>>>>> >> > >>>>>> >>>>Do others have thoughts on the matter? Do we need this > >>>>>> >> > >>>>>> >>feature at all? > >>>>>> >> > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>Christer Holmberg (JO/LMF) wrote: > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>Hi, > >>>>>> >>>>> > >>>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 > discussion I > >>>>>> >>>> > >>>>>> >>>>am bringing to the list the issue about being able to > >>>>>> >>>>indicate the max content size a node is able=20 > to receive. > >>>>>> >>>>Also, as input, in chapter 4 of > >>>>>> =20 > >>>>>> > >>>>>>> draft-rosenberg-simple-messaging-requirements-01.txt there is > >>>>>> > >>>>>> > >>>>>> >>>>a requirement for such functionality: > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 > the maximum > >>>>>> >>>> > >>>>>> >>>>message size it is willing to receive. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>I think it would be useful if clients could=20 > indicate the > >>>>>> >>>> > >>>>>> >>>>maximum payload size he is able to receive,=20 > and also send, > >>>>>> >>>>either per type or stream. Note that I am=20 > talking about the > >>>>>> >>>>total message/content size, not the size of individual > >>>>>> >>>>fragments (the spec does say that messages=20 > bigger than 2k > >>>>>> >>>>should be fragmented). > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>If the max size is dependent on the media=20 > type, max size > >>>>>> >>>> > >>>>>> >>>>could be defined as a accept-type token paramter: > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>example: > >>>>>> >>>>> > >>>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, > >>>>>> >>>> > >>>>>> >>>>Y;max-send=3D2000;max-receive=3D500 > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>And, if the message size it not type=20 > dependent, generic max > >>>>>> >>>> > >>>>>> >>>>size attributes could be used. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>example: > >>>>>> >>>>> > >>>>>> >>>>>a=3Dmax-send: 1000 > >>>>>> >>>>>a=3Dmax-receive:1000 > >>>>>> >>>>> > >>>>>> >>>>>Even if one is not going to send more than=20 > the other party > >>>>>> >>>> > >>>>>> >>>>indicates he is able to receive I still think it is=20 > >>> > >>> > >>> important > >>> > >>>>>> >>>>that a node can indicate how much he is able=20 > to send. For > >>>>>> >>>>example, the remote node may reserve memory=20 > >>> > >>> > >>> according to that > >>> > >>>>>> >>>>information, and/or intermediate proxies may do > >>>>>> >>>>forking/routing based on the client capabilities. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>An MSRP "message size too big" error code=20 > could also be > >>>>>> >>>> > >>>>>> >>>>useful, if a node for whatever reason is not able=20 > >>> > >>> > >>> to accept a > >>> > >>>>>> >>>>SEND message. This may be due to that the=20 > remote node is > >>>>>> >>>>sending more data than was agreed in the=20 > offer/answer, but > >>>>>> >>>>also due to that the receiving node for a=20 > short period isn't > >>>>>> >>>>able to receive the agreed data size (if the=20 > max size change > >>>>>> >>>>is permanent a new offer should of course be sent,=20 > >>> > >>> > >>> instead of > >>> > >>>>>> >>>>sending an error reply to every SEND). At the=20 > >>> > >>> > >>> interim meeting > >>> > >>>>>> >>>>is was desired to have a mechanism to "interrupt" the > >>>>>> >>>>receival of a message, and this error code=20 > could be used to > >>>>>> >>>>indicate that. The sender would then stop sending the > >>>>>> >>>>message, and any possible yet unsent fragments. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>>Regards, > >>>>>> >>>>> > >>>>>> >>>>>Christer Holmberg > >>>>>> >>>>>Ericsson Finland > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>_______________________________________________ > >>>>>> >>>>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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> This message has been scanned for viruses by MailControl -=20 > >> > >> > >> www.mailcontrol.com > >> > >>>>> > >>>>> > >>>>>=20 > -------------------------------------------------------------- > ----------=20 > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > --=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 12:12:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25384 for ; Wed, 9 Jun 2004 12:12:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY5gi-0007Jv-9Q for simple-archive@ietf.org; Wed, 09 Jun 2004 12:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY5d5-0005A8-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 12:08:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY5Zt-00038D-01; Wed, 09 Jun 2004 12:05:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY5Qt-0001tW-Cw; Wed, 09 Jun 2004 11:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4x9-00016k-B4; Wed, 09 Jun 2004 11:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4oI-0002aa-5f for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:16: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 FAA04203 for ; Wed, 9 Jun 2004 05:14:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXz9z-0000qv-MT for simple@ietf.org; Wed, 09 Jun 2004 05:14:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXz96-00002J-00 for simple@ietf.org; Wed, 09 Jun 2004 05:13:21 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BXz8O-00071I-00 for simple@ietf.org; Wed, 09 Jun 2004 05:12:36 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i599CQH16229; Wed, 9 Jun 2004 12:12:26 +0300 (EET DST) X-Scanned: Wed, 9 Jun 2004 12:12:16 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i599CGPc031612; Wed, 9 Jun 2004 12:12:16 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00ykPByy; Wed, 09 Jun 2004 12:12:14 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i599C4H19557; Wed, 9 Jun 2004 12:12:04 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 12:11:54 +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] Re: MSRP: Max message size indication Date: Wed, 9 Jun 2004 12:11:53 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C1B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication thread-index: AcRN9R/EQpaqjYsRRXeFEtP2vLOu0AABiQug To: X-OriginalArrivalTime: 09 Jun 2004 09:11:54.0263 (UTC) FILETIME=[CEAD8A70:01C44E01] Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, simple@ietf.org, christer.holmberg@ericsson.com, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09.June.2004 10:39 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: bcampbell@dynamicsoft.com; Niemi Aki (Nokia-M/Espoo); > cboulton@ubiquity.com; simple@ietf.org;=20 > christer.holmberg@ericsson.com; > jdrosen@dynamicsoft.com > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Hisham, >=20 > so, what is the purpose of the *advanced* requirements? Are they going > to be used to develop a new protocol different from MSRP, are=20 > they going > to be used to develop extensions to MSRP, or are they going to be just > ignored? They will be used to develop extensions to MSRP as well as solutions = that will just work with MSRP (isComposing is one example), depending on = the requirement. >=20 > In any case, if these are not the requirements that apply to=20 > MSRP, where > are the requirements that do apply? Some of those requirements do apply to MSRP, but as extensions. I am = unaware of any other requirements documents besides RFC2779. Regards, Hisham >=20 > Gonzalo >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > This draft is called "Advanced Instant Messaging=20 > Requirements for the Session Initiation Protocol". Note the=20 > word "Advanced". It means additional, not base requirements. > >=20 > > We are not at a stage yet where solutions for advanced=20 > requirements can be discussed. The draft is not even a WG=20 > item. There are, however, some exceptions: In some cases, it=20 > was found necessary to incorporate some of the advanced=20 > features to make the protocol usable (eg: DSNs). Max message=20 > size is not one of those. > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > >>Sent: 08.June.2004 22:14 > >>To: Ben Campbell > >>Cc: Niemi Aki (Nokia-M/Espoo); Khartabil Hisham=20 > >>(Nokia-TP-MSW/Helsinki); > >>Chris Boulton; simple@ietf.org; Christer Holmberg (JO/LMF); Jonathan > >>Rosemberg > >>Subject: Re: [Simple] Re: MSRP: Max message size indication > >> > >> > >>Ben, > >> > >>let me try to understand the discussion here. We have a=20 > requirements=20 > >>document (written by Jonathan) that says the following: > >> > >>http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes > >>saging-requirements-01.txt > >> > >> "REQ-CONTENT-1: A UA MUST be able to indicate the=20 > maximum message > >> size it is willing to receive." > >> > >>According to the requirements, the protocol MUST support=20 > it... do you=20 > >>want to go through the requirements phase again at this point? > >> > >>Gonzalo > >> > >> > >> > >>Ben Campbell wrote: > >> > >> > >>>So far, I have had 4 people (counting myself) respond=20 > >> > >>no/no, 2 respond=20 > >> > >>>yes/yes, and one equivocation that I interpret as yes/no. > >>> > >>>This is a pretty small fraction of the work group. If only=20 > >> > >>seven people=20 > >> > >>>care enough to even comment, I'm not sure we have a mandate=20 > >> > >>for this. > >> > >>>So, if there is anyone out there who cares but has not said=20 > >> > >>so, please=20 > >> > >>>do so soon. > >>> > >>>Aki Niemi wrote: > >>> > >>> > >>>>I'll have to vote for no/no. I don't think it solves the=20 > >> > >>real problem, > >> > >>>>which is not having the sender/recipient ability to abort transfer > >>>>mid-message. > >>>> > >>>>Cheers, > >>>>Aki > >>>> > >>>>On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > >>>> > >>>> > >>>>>I'd like to try and get some closure on this: > >>>>> > >>>>>Please answer yes or no to the following: > >>>>> > >>>>>1) Should we add the optional signaling of the maximum=20 > >> > >>content size=20 > >> > >>>>>you are willing to _receive_ into the SDP exchange. > >>>>> > >>>>>2) Should we add the optional signaling of the maximum=20 > >> > >>content size=20 > >> > >>>>>you are planning to _send_ into the SDP exchange. > >>>>> > >>>>>3) If either 1 or 2 is yes, do we send one value for the=20 > >> > >>session, or=20 > >> > >>>>>one value per each type for which we have indicated support. > >>>>> > >>>>>My personal opinions: > >>>>> > >>>>>No and No. In all honesty, I think this could be a useful=20 > >> > >>feature,=20 > >> > >>>>>but I don't think MSRP has to have it to function. I am=20 > >> > >>voting no,=20 > >> > >>>>>not because I disagree with the feature, but because I=20 > >> > >>don't want to=20 > >> > >>>>>add additional work to completing MSRP unless it is absolutely=20 > >>>>>necessary. But if consensus says we need it, I do not=20 > >> > >>object on any=20 > >> > >>>>>technical basis. > >>>> > >=20 >=20 > --=20 > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 12:13:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25704 for ; Wed, 9 Jun 2004 12:13:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY5i2-0000Ix-11 for simple-archive@ietf.org; Wed, 09 Jun 2004 12:13:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY5fJ-0006A8-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 12:11:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BY5bI-00048W-00; Wed, 09 Jun 2004 12:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5Om-0006Q0-Tk; Wed, 09 Jun 2004 11:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4wg-0008R5-4j for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:24: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 HAA08973 for ; Wed, 9 Jun 2004 07:11:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY0zU-0004ts-GZ for simple@ietf.org; Wed, 09 Jun 2004 07:11:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY0yU-00044a-00 for simple@ietf.org; Wed, 09 Jun 2004 07:10:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BY0xf-00030Y-00 for simple@ietf.org; Wed, 09 Jun 2004 07:09:39 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i59B9Sbo020160; Wed, 9 Jun 2004 07:09:28 -0400 (EDT) Message-ID: <40C6EFCC.9090800@dynamicsoft.com> Date: Wed, 09 Jun 2004 07:09:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] Re: MSRP: Max message size indication References: <40C614DA.1040900@dynamicsoft.com> In-Reply-To: <40C614DA.1040900@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i59B9Sbo020160 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, hisham.khartabil@nokia.com, Chris Boulton , Aki Niemi , "Christer Holmberg \(JO/LMF\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I havent been following this discussion entirely, but here is my input. The requirement in the requirements document is strictly talking about=20 indicating the maximum an endpoint is willing to receive. The primary=20 purpose of this is for devices like mobile handsets, which want to be=20 able to tell a peer "hey, don't send a huge image, I don't want to pay=20 for that". I think its better to indicate this during the sdp exchange,=20 rather than have the mobile cut off an incoming messages once it reaches=20 that limit. -Jonathan R. Ben Campbell wrote: > I just replied to a similar comment from Gonzalo. I had forgotten about= =20 > that requirement in the draft. That requirement seems to me to require=20 > being able to indicate the max size you are willing to receive. It does= =20 > not seem to require indicating the max size you intend to send. >=20 > Christer Holmberg (JO/LMF) wrote: >=20 >> Hi Ben, >> >> If for no other reason (ie if nobody thinks the usage examples I've=20 >> given are valid), I think the requirement (REQ-CONTENT-1) is the=20 >> "mandate" we need. Or, have I missunderstood the requirment? Of course= =20 >> the meaning of the requirement could be that one should be able to=20 >> indicate the size in an error response, but the text about=20 >> offer/answer, and that negotiation is needed , at least to me sounds=20 >> that negotiation is what it's really about. >> >> Now, of course, if there are technical reasons and/or big problems why= =20 >> a requirement can not be fullfilled we need to re-visit the=20 >> requirments, and possibly change/remove something. But, so far most of= =20 >> the comments have been about that fact that this doesn't solve the=20 >> issue when messages need to be rejected. However, the max-size=20 >> attribute is not supposed to solve that issue, and the requirment says= =20 >> nothing about that issue, so I don't see why we should remove a=20 >> requirement just because it doesn't solve something it's not even=20 >> supposed to solve... >> >> If we remove requirements just becuase we suddenly don't think they=20 >> are needed I wonder how much work we have put on the requirements in=20 >> the first place, especially when we have came this far with the actual= =20 >> protocol. >> HOWEVER, I would really not like to use the requirements as an=20 >> argument, and I really hope we all think we have stable requirements -= =20 >> instead I have tried to describe the technical reasons why I think=20 >> this would be useful. >> >> Regards, >> >> Christer Holmberg >> Ericsson Finland >> >> >> >> >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> Sent: 8. kes=E4kuuta 2004 20:46 >>> To: Aki Niemi >>> Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org; Chris= ter >>> Holmberg (JO/LMF) >>> Subject: Re: [Simple] Re: MSRP: Max message size indication >>> >>> >>> So far, I have had 4 people (counting myself) respond no/no, 2=20 >>> respond yes/yes, and one equivocation that I interpret as yes/no. >>> >>> This is a pretty small fraction of the work group. If only seven=20 >>> people care enough to even comment, I'm not sure we have a mandate=20 >>> for this. >>> >>> So, if there is anyone out there who cares but has not said so,=20 >>> please do so soon. >>> >>> Aki Niemi wrote: >>> >>> >>>> I'll have to vote for no/no. I don't think it solves the=20 >>> >>> >>> real problem, >>> >>>> which is not having the sender/recipient ability to abort transfer >>>> mid-message. >>>> >>>> Cheers, >>>> Aki >>>> >>>> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: >>>> >>>> >>>>> I'd like to try and get some closure on this: >>>>> >>>>> Please answer yes or no to the following: >>>>> >>>>> 1) Should we add the optional signaling of the maximum=20 >>> >>> >>> content size you >>> >>>>> are willing to _receive_ into the SDP exchange. >>>>> >>>>> 2) Should we add the optional signaling of the maximum=20 >>> >>> >>> content size you >>> >>>>> are planning to _send_ into the SDP exchange. >>>>> >>>>> 3) If either 1 or 2 is yes, do we send one value for the=20 >>> >>> >>> session, or one >>> >>>>> value per each type for which we have indicated support. >>>>> >>>>> My personal opinions: >>>>> >>>>> No and No. In all honesty, I think this could be a useful=20 >>> >>> >>> feature, but I >>> >>>>> don't think MSRP has to have it to function. I am voting=20 >>> >>> >>> no, not because >>> >>>>> I disagree with the feature, but because I don't want to=20 >>> >>> >>> add additional >>> >>>>> work to completing MSRP unless it is absolutely necessary. But if=20 >>>>> consensus says we need it, I do not object on any technical basis. >>>>> >>>>> >>>>> >>>>> >>>>> Chris Boulton wrote: >>>>> >>>>> >>>>> >>>>>> I think this feature would certainly be useful for max=20 >>> >>> >>> receive (if it was type specific) BUT I am not convinced about send. >>> >>>>>> Chris. >>>>>> >>>>>> >>>>>> -----Original Message----- From: Ben Campbell=20 >>>>>> [mailto:bcampbell@dynamicsoft.com] Sent: Tue 25/05/2004 18:27=20 >>>>>> To: Christer Holmberg (JO/LMF) Cc:=20 >>>>>> hisham.khartabil@nokia.com; simple@ietf.org Subject: Re:=20 >>>>>> [Simple] Re: MSRP: Max message size indication >>>>>> =20 >>>>>> =20 >>>>>> >>>>>> Let me step up a level: >>>>>> =20 >>>>>> By the required vs useful discussion, I was referring=20 >>> >>> >>> to the feature of >>> >>>>>> being able to signal size limitations itself, rather=20 >>> >>> >>> than some aspect of >>> >>>>>> the feature. >>>>>> =20 >>>>>> So, what do others about whether the feature of being=20 >>> >>> >>> able to signal >>> >>>>>> message size limits is required? >>>>>> =20 >>>>>> Christer Holmberg (JO/LMF) wrote: >>>>>> =20 >>>>>> > Hi, >>>>>> > >>>>>> > >>>>>> >>(Ignore my yet-another-empty reply. This time I blame=20 >>> >>> >>> the combined >>> >>>>>> >>ergonomics of Thunderbird and my laptop.) >>>>>> >> >>>>>> >>That brings up an interesting meta-question. What is the bar >>>>>> >>for putting new features into MSRP at this stage? Is=20 >>> >>> >>> "useful" enough? Or >>> >>>>>> >>should we limit new features to things that we decide=20 >>> >>> >>> are "required." >>> >>>>>> > >>>>>> > >>>>>> > Well, the max-receive is required, and I think it is=20 >>> >>> >>> very useful. As I wrote earlier, the question is if it should be=20 >>> possible to indicate separate values for different media types. >>> >>>>>> > >>>>>> > The max-send is not required, but I still think it=20 >>> >>> >>> would be very useful. Earlier I gave some examples I think are very=20 >>> valid (nodes may try to reserve memory according to how much big=20 >>> messages then can expect to receive, redirection/forking may be done=20 >>> based on the information etc etc etc). It wouldn't have any impacts=20 >>> on the protocol functionality itself, and there would be no interop=20 >>> problems with nodes that don't understand the max-send=20 >>> attribute/parameter (or just don't care about it). >>> >>>>>> > >>>>>> > Regards, >>>>>> > >>>>>> > Christer Holmberg >>>>>> > Ericsson Finland >>>>>> > >>>>>> > >>>>>> > >>>>>> >>hisham.khartabil@nokia.com wrote: >>>>>> >> >>>>>> >> >>>>>> >>>I think max-receive is useful, but not max-send. >>>>>> >>> >>>>>> >>>/Hisham >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>>>-----Original Message----- >>>>>> >>>>From: simple-bounces@ietf.org >>>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>>> >>>>Of ext Ben Campbell >>>>>> >>>>Sent: 25.May.2004 17:49 >>>>>> >>>>To: Christer Holmberg (JO/LMF) >>>>>> >>>>Cc: 'simple@ietf.org' >>>>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>(Oops, itchy trigger finger--ignore my last mail on=20 >>> >>> >>> the subject.) >>> >>>>>> >>>> >>>>>> >>>>I do not have strong feelings on this as a=20 >>> >>> >>> requirement. If we >>> >>>>>> >>>>do want to >>>>>> >>>>do it, the general approach seems good at the first=20 >>> >>> >>> read, anyway. I >>> >>>>>> >>>>don't think there is a need for the non-type specific size >>>>>> >> >>>>>> >>attribute. >>>>>> >> >>>>>> >>>>The only advantage would be to reduce size of the SDP. I >>>>>> >>>>don't see that >>>>>> >>>>as a big requirement, since it normally only happens one >>>>>> >> >>>>>> >>per session. >>>>>> >> >>>>>> >>>>Do others have thoughts on the matter? Do we need this >>>>>> >> >>>>>> >>feature at all? >>>>>> >> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>Christer Holmberg (JO/LMF) wrote: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>Hi, >>>>>> >>>>> >>>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP discussion I >>>>>> >>>> >>>>>> >>>>am bringing to the list the issue about being able to >>>>>> >>>>indicate the max content size a node is able to receive. >>>>>> >>>>Also, as input, in chapter 4 of >>>>>> =20 >>>>>> >>>>>>> draft-rosenberg-simple-messaging-requirements-01.txt there is >>>>>> >>>>>> >>>>>> >>>>a requirement for such functionality: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate the maximum >>>>>> >>>> >>>>>> >>>>message size it is willing to receive. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>I think it would be useful if clients could indicate the >>>>>> >>>> >>>>>> >>>>maximum payload size he is able to receive, and also send, >>>>>> >>>>either per type or stream. Note that I am talking about th= e >>>>>> >>>>total message/content size, not the size of individual >>>>>> >>>>fragments (the spec does say that messages bigger than 2k >>>>>> >>>>should be fragmented). >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>If the max size is dependent on the media type, max size >>>>>> >>>> >>>>>> >>>>could be defined as a accept-type token paramter: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>example: >>>>>> >>>>> >>>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, >>>>>> >>>> >>>>>> >>>>Y;max-send=3D2000;max-receive=3D500 >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>And, if the message size it not type dependent, generic m= ax >>>>>> >>>> >>>>>> >>>>size attributes could be used. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>example: >>>>>> >>>>> >>>>>> >>>>>a=3Dmax-send: 1000 >>>>>> >>>>>a=3Dmax-receive:1000 >>>>>> >>>>> >>>>>> >>>>>Even if one is not going to send more than the other part= y >>>>>> >>>> >>>>>> >>>>indicates he is able to receive I still think it is=20 >>> >>> >>> important >>> >>>>>> >>>>that a node can indicate how much he is able to send. For >>>>>> >>>>example, the remote node may reserve memory=20 >>> >>> >>> according to that >>> >>>>>> >>>>information, and/or intermediate proxies may do >>>>>> >>>>forking/routing based on the client capabilities. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>An MSRP "message size too big" error code could also be >>>>>> >>>> >>>>>> >>>>useful, if a node for whatever reason is not able=20 >>> >>> >>> to accept a >>> >>>>>> >>>>SEND message. This may be due to that the remote node is >>>>>> >>>>sending more data than was agreed in the offer/answer, but >>>>>> >>>>also due to that the receiving node for a short period isn= 't >>>>>> >>>>able to receive the agreed data size (if the max size chan= ge >>>>>> >>>>is permanent a new offer should of course be sent,=20 >>> >>> >>> instead of >>> >>>>>> >>>>sending an error reply to every SEND). At the=20 >>> >>> >>> interim meeting >>> >>>>>> >>>>is was desired to have a mechanism to "interrupt" the >>>>>> >>>>receival of a message, and this error code could be used t= o >>>>>> >>>>indicate that. The sender would then stop sending the >>>>>> >>>>message, and any possible yet unsent fragments. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>Regards, >>>>>> >>>>> >>>>>> >>>>>Christer Holmberg >>>>>> >>>>>Ericsson Finland >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>_______________________________________________ >>>>>> >>>>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 >>>>>> >>>>>> >>>>>> >>>>>> This message has been scanned for viruses by MailControl -=20 >> >> >> www.mailcontrol.com >> >>>>> >>>>> >>>>> -------------------------------------------------------------------= -----=20 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 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-bounces@ietf.org Wed Jun 9 13:13:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29649 for ; Wed, 9 Jun 2004 13:13:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY6dz-0005Cg-Kn for simple-archive@ietf.org; Wed, 09 Jun 2004 13:13:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6bb-0003ez-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 13:11:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY6YE-00010w-01; Wed, 09 Jun 2004 13:07:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY6JL-0006pn-Jd; Wed, 09 Jun 2004 12:52:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5mL-000893-UB; Wed, 09 Jun 2004 12:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5RY-0007uq-Hf for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:56: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 FAA04735 for ; Wed, 9 Jun 2004 05:29:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXzOX-0005Xg-Cn for simple@ietf.org; Wed, 09 Jun 2004 05:29:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXzNU-0004i0-00 for simple@ietf.org; Wed, 09 Jun 2004 05:28:12 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BXzMX-00034s-00 for simple@ietf.org; Wed, 09 Jun 2004 05:27:13 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i599QXs12558 for ; Wed, 9 Jun 2004 04:26:34 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Jun 2004 10:26:40 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C414D7F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Ben Campbell Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Wed, 9 Jun 2004 10:26:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Before we start accepting draft-rosenberg-simple-messaging-requirements-01.txt as the final answer on messaging requirements, I don't actually remember any discussion that adopted these as the basis for messaging. I do remember Jonathan, after some protocol discussion, reissuing the document and saying something like it was time to go back to discussing requirements, but I remember no pronouncement from anybody, let alone the working group chairs, that they therefore agreed these were the requirements we were now working to. Further there have been other requirements documents, e.g. draft-mahy-simple-im-protocol-reqs that have been equally ignored. So why should I believe any of these documents as anything more that the input by the original authors? regards Keith > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 08 June 2004 20:21 > To: Gonzalo Camarillo > Cc: Jonathan Rosemberg; hisham.khartabil@nokia.com; Aki > Niemi; Christer > Holmberg (JO/LMF); Chris Boulton; simple@ietf.org > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > > > Gonzalo Camarillo wrote: > > > Ben, > > > > let me try to understand the discussion here. We have a > requirements > > document (written by Jonathan) that says the following: > > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes > saging-requirements-01.txt > > > > > > "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message > > size it is willing to receive." > > > > According to the requirements, the protocol MUST support > it... do you > > want to go through the requirements phase again at this point? > > Ah, I missed making that connection. Avoiding the question of > which came > first (agreed upon MSRP requirements and that document) for > the moment, > this would seem to support the yes/no vote. (That is, ability > to express > max you are willing to receive vs max you intend to send.) > > Since we have a written requirement, I propose we move > forward with "max > I am willing to receive" part, but not "the max I intend to > send" part. > > > > > Gonzalo > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 13:13:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29667 for ; Wed, 9 Jun 2004 13:13:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY6e0-0005D8-7f for simple-archive@ietf.org; Wed, 09 Jun 2004 13:13:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6bc-0003f8-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 13:11:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY6YF-00010w-00; Wed, 09 Jun 2004 13:07:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY6JJ-0006pd-AA; Wed, 09 Jun 2004 12:52:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5mJ-00088b-9C; Wed, 09 Jun 2004 12:18:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5RW-0007uq-CG for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:56:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06447 for ; Wed, 9 Jun 2004 06:17:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY094-0006Uj-Sx for simple@ietf.org; Wed, 09 Jun 2004 06:17:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY083-0005dq-00 for simple@ietf.org; Wed, 09 Jun 2004 06:16:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY06z-0004lS-00 for simple@ietf.org; Wed, 09 Jun 2004 06:15:13 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY071-0007u6-KK for simple@ietf.org; Wed, 09 Jun 2004 06:15:15 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i59AF1Ah029990 for ; Wed, 9 Jun 2004 12:15:01 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jun 2004 12:15:01 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Jun 2004 12:15:01 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Ben Campbell'" Subject: RE: [Simple] Re: MSRP: Ending a session Date: Wed, 9 Jun 2004 12:14:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 09 Jun 2004 10:15:01.0578 (UTC) FILETIME=[A017F2A0:01C44E0A] Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Ben, >>Chapter 6.5.4 in the MSRP draft (version -06) says: >> >>"When either endpoint in an MSRP session wishes to end the >>session, it first signals its intent using the normal processing for the >>signaling protocol. For example, in SIP, it would send a >>BYE request to the peer. After agreeing to end the session, the host endpoint >>MUST release any resources acquired as part of the session." >> >>Later in the chapter it is also described how possible >>outstanding MSRP transactions are handled when a session is to be released. >> >>Now, I don't think it should be a must for a node to wait >>for a node to receive the BYE response before the TCP >>resources are released. Many nodes releases the media >>resources at the same time as the BYE is sent. And, even if >>would keep the connection open for possible outstanding MSRP >>transactions they would most likely be "lost" anyway, since a >>user will not (in gateway scenarios may not even be able to) >>wait for possible messages after the release message is sent. > >The intent was not that you must wait until that point, but that you >must eventually release the resources. I agree it could be worded a >little better. [CHH] Again, RFC3261 is very clear about this, so I don't think we shall define anything different than that. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 13:16:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29999 for ; Wed, 9 Jun 2004 13:16:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY6gt-000738-2Z for simple-archive@ietf.org; Wed, 09 Jun 2004 13:16:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6fA-0005nK-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 13:14:57 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BY6dP-0004du-00; Wed, 09 Jun 2004 13:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5ql-0001D1-EU; Wed, 09 Jun 2004 12:22:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5SS-0007uq-Vp for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:57: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 DAA01155 for ; Wed, 9 Jun 2004 03:42:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXxiv-0003rj-Jv for simple@ietf.org; Wed, 09 Jun 2004 03:42:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXxht-00031D-00 for simple@ietf.org; Wed, 09 Jun 2004 03:41:10 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BXxgi-0001O1-00 for simple@ietf.org; Wed, 09 Jun 2004 03:39:56 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i597dLLc020816; Wed, 9 Jun 2004 02:39:21 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.157]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB8VWT7; Wed, 9 Jun 2004 02:38:52 -0500 Message-ID: <40C6BEA6.60508@ericsson.com> Date: Wed, 09 Jun 2004 10:39:18 +0300 X-Sybari-Trust: 90eaf6b6 100f6658 c3a3caf7 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: hisham.khartabil@nokia.com Subject: Re: [Simple] Re: MSRP: Max message size indication References: <2038BCC78B1AD641891A0D1AE133DBB701797C18@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C18@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org, christer.holmberg@ericsson.com, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hisham, so, what is the purpose of the *advanced* requirements? Are they going to be used to develop a new protocol different from MSRP, are they going to be used to develop extensions to MSRP, or are they going to be just ignored? In any case, if these are not the requirements that apply to MSRP, where are the requirements that do apply? Gonzalo hisham.khartabil@nokia.com wrote: > This draft is called "Advanced Instant Messaging Requirements for the Session Initiation Protocol". Note the word "Advanced". It means additional, not base requirements. > > We are not at a stage yet where solutions for advanced requirements can be discussed. The draft is not even a WG item. There are, however, some exceptions: In some cases, it was found necessary to incorporate some of the advanced features to make the protocol usable (eg: DSNs). Max message size is not one of those. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>Sent: 08.June.2004 22:14 >>To: Ben Campbell >>Cc: Niemi Aki (Nokia-M/Espoo); Khartabil Hisham >>(Nokia-TP-MSW/Helsinki); >>Chris Boulton; simple@ietf.org; Christer Holmberg (JO/LMF); Jonathan >>Rosemberg >>Subject: Re: [Simple] Re: MSRP: Max message size indication >> >> >>Ben, >> >>let me try to understand the discussion here. We have a requirements >>document (written by Jonathan) that says the following: >> >>http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes >>saging-requirements-01.txt >> >> "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message >> size it is willing to receive." >> >>According to the requirements, the protocol MUST support it... do you >>want to go through the requirements phase again at this point? >> >>Gonzalo >> >> >> >>Ben Campbell wrote: >> >> >>>So far, I have had 4 people (counting myself) respond >> >>no/no, 2 respond >> >>>yes/yes, and one equivocation that I interpret as yes/no. >>> >>>This is a pretty small fraction of the work group. If only >> >>seven people >> >>>care enough to even comment, I'm not sure we have a mandate >> >>for this. >> >>>So, if there is anyone out there who cares but has not said >> >>so, please >> >>>do so soon. >>> >>>Aki Niemi wrote: >>> >>> >>>>I'll have to vote for no/no. I don't think it solves the >> >>real problem, >> >>>>which is not having the sender/recipient ability to abort transfer >>>>mid-message. >>>> >>>>Cheers, >>>>Aki >>>> >>>>On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: >>>> >>>> >>>>>I'd like to try and get some closure on this: >>>>> >>>>>Please answer yes or no to the following: >>>>> >>>>>1) Should we add the optional signaling of the maximum >> >>content size >> >>>>>you are willing to _receive_ into the SDP exchange. >>>>> >>>>>2) Should we add the optional signaling of the maximum >> >>content size >> >>>>>you are planning to _send_ into the SDP exchange. >>>>> >>>>>3) If either 1 or 2 is yes, do we send one value for the >> >>session, or >> >>>>>one value per each type for which we have indicated support. >>>>> >>>>>My personal opinions: >>>>> >>>>>No and No. In all honesty, I think this could be a useful >> >>feature, >> >>>>>but I don't think MSRP has to have it to function. I am >> >>voting no, >> >>>>>not because I disagree with the feature, but because I >> >>don't want to >> >>>>>add additional work to completing MSRP unless it is absolutely >>>>>necessary. But if consensus says we need it, I do not >> >>object on any >> >>>>>technical basis. >>>> > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 13:36:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01683 for ; Wed, 9 Jun 2004 13:36:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY703-0002HB-7L for simple-archive@ietf.org; Wed, 09 Jun 2004 13:36:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6uv-0007eK-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 13:31:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY6rS-0005tS-00; Wed, 09 Jun 2004 13:27:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY6lN-0000m1-Qf; Wed, 09 Jun 2004 13:21:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5ro-0001pi-Dh; Wed, 09 Jun 2004 12:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5T3-0000cK-1l for simple@megatron.ietf.org; Wed, 09 Jun 2004 11:58: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 CAA29376 for ; Wed, 9 Jun 2004 02:50:25 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXwum-0000rh-67 for simple@ietf.org; Wed, 09 Jun 2004 02:50:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXwtt-00000z-00 for simple@ietf.org; Wed, 09 Jun 2004 02:49:29 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BXwso-0006xT-00 for simple@ietf.org; Wed, 09 Jun 2004 02:48:22 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i596m5J13320; Wed, 9 Jun 2004 09:48:05 +0300 (EET DST) X-Scanned: Wed, 9 Jun 2004 09:47:49 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i596lnvo017395; Wed, 9 Jun 2004 09:47:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 005YaNsd; Wed, 09 Jun 2004 09:47:37 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i596lWH09487; Wed, 9 Jun 2004 09:47:32 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 09:47:32 +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] Re: MSRP: Max message size indication Date: Wed, 9 Jun 2004 09:47:31 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C18@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication thread-index: AcRNjPY3uzMkPon4QgGV+6azz8wV0AAX6Fxw To: , X-OriginalArrivalTime: 09 Jun 2004 06:47:32.0986 (UTC) FILETIME=[A4278DA0:01C44DED] Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, christer.holmberg@ericsson.com, cboulton@ubiquity.com, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This draft is called "Advanced Instant Messaging Requirements for the = Session Initiation Protocol". Note the word "Advanced". It means = additional, not base requirements. We are not at a stage yet where solutions for advanced requirements can = be discussed. The draft is not even a WG item. There are, however, some = exceptions: In some cases, it was found necessary to incorporate some of = the advanced features to make the protocol usable (eg: DSNs). Max = message size is not one of those. Regards, Hisham > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 08.June.2004 22:14 > To: Ben Campbell > Cc: Niemi Aki (Nokia-M/Espoo); Khartabil Hisham=20 > (Nokia-TP-MSW/Helsinki); > Chris Boulton; simple@ietf.org; Christer Holmberg (JO/LMF); Jonathan > Rosemberg > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Ben, >=20 > let me try to understand the discussion here. We have a requirements=20 > document (written by Jonathan) that says the following: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes > saging-requirements-01.txt >=20 > "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message > size it is willing to receive." >=20 > According to the requirements, the protocol MUST support it... do you=20 > want to go through the requirements phase again at this point? >=20 > Gonzalo >=20 >=20 >=20 > Ben Campbell wrote: >=20 > > So far, I have had 4 people (counting myself) respond=20 > no/no, 2 respond=20 > > yes/yes, and one equivocation that I interpret as yes/no. > >=20 > > This is a pretty small fraction of the work group. If only=20 > seven people=20 > > care enough to even comment, I'm not sure we have a mandate=20 > for this. > >=20 > > So, if there is anyone out there who cares but has not said=20 > so, please=20 > > do so soon. > >=20 > > Aki Niemi wrote: > >=20 > >> I'll have to vote for no/no. I don't think it solves the=20 > real problem, > >> which is not having the sender/recipient ability to abort transfer > >> mid-message. > >> > >> Cheers, > >> Aki > >> > >> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > >> > >>> I'd like to try and get some closure on this: > >>> > >>> Please answer yes or no to the following: > >>> > >>> 1) Should we add the optional signaling of the maximum=20 > content size=20 > >>> you are willing to _receive_ into the SDP exchange. > >>> > >>> 2) Should we add the optional signaling of the maximum=20 > content size=20 > >>> you are planning to _send_ into the SDP exchange. > >>> > >>> 3) If either 1 or 2 is yes, do we send one value for the=20 > session, or=20 > >>> one value per each type for which we have indicated support. > >>> > >>> My personal opinions: > >>> > >>> No and No. In all honesty, I think this could be a useful=20 > feature,=20 > >>> but I don't think MSRP has to have it to function. I am=20 > voting no,=20 > >>> not because I disagree with the feature, but because I=20 > don't want to=20 > >>> add additional work to completing MSRP unless it is absolutely=20 > >>> necessary. But if consensus says we need it, I do not=20 > object on any=20 > >>> technical basis. > >> >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 15:55:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14404 for ; Wed, 9 Jun 2004 15:55:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY9AT-0005IZ-W9 for simple-archive@ietf.org; Wed, 09 Jun 2004 15:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY97q-0003O4-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 15:52:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY94J-0001QZ-02; Wed, 09 Jun 2004 15:49:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY8vB-0000jO-9D; Wed, 09 Jun 2004 15:39:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY8pM-00067s-PD; Wed, 09 Jun 2004 15:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY8jt-0003BH-DV for simple@megatron.ietf.org; Wed, 09 Jun 2004 15: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 PAA12624 for ; Wed, 9 Jun 2004 15:27:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY8js-00003j-4N for simple@ietf.org; Wed, 09 Jun 2004 15:27:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY8ip-0006ze-00 for simple@ietf.org; Wed, 09 Jun 2004 15:26:52 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1BY8hv-0005UP-00 for simple@ietf.org; Wed, 09 Jun 2004 15:25:55 -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 i59JNKV4012953; Wed, 9 Jun 2004 14:23:22 -0500 (CDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jun 2004 14:23:20 -0500 Message-ID: From: Adam Roach To: Ben Campbell , "Christer Holmberg (JO/LMF)" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Wed, 9 Jun 2004 14:23:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: pkyzivat@cisco.com, "'hisham.khartabil@nokia.com'" , cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > I don't want to get too deep in this until we have results on > the "vote" (running neck and neck at the moment.) Put me in the no/no camp. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 9 17:56:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27681 for ; Wed, 9 Jun 2004 17:56:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYB3r-0000lN-6x for simple-archive@ietf.org; Wed, 09 Jun 2004 17:56:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYB17-0006zF-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 17:53:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYAys-00059Z-00; Wed, 09 Jun 2004 17:51:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYAqO-0004Kt-Fx; Wed, 09 Jun 2004 17:42:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYAm7-0003Un-0G; Wed, 09 Jun 2004 17:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYARN-0002MP-Ap for simple@megatron.ietf.org; Wed, 09 Jun 2004 17:16: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 RAA22815 for ; Wed, 9 Jun 2004 17:16:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYARL-00074c-SL for simple@ietf.org; Wed, 09 Jun 2004 17:16:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYAFt-0003oY-00 for simple@ietf.org; Wed, 09 Jun 2004 17:05:06 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1BYA7b-0000TK-00 for simple@ietf.org; Wed, 09 Jun 2004 16:56:32 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i59KsS0J024085; Wed, 9 Jun 2004 15:54:28 -0500 (CDT) Message-ID: <40C77904.5020003@alcatel.com> Date: Wed, 09 Jun 2004 15:54:28 -0500 From: Alex Audu 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: Adam Roach Subject: Re: [Simple] Re: MSRP: Max message size indication References: In-Reply-To: Cc: "'hisham.khartabil@nokia.com'" , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" , pkyzivat@cisco.com, cboulton@ubiquity.com, Ben Campbell X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alex.audu@alcatel.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1703206399==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --===============1703206399== Content-Type: multipart/alternative; boundary="------------040805090701050201010103" This is a multi-part message in MIME format. --------------040805090701050201010103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think there is great value in end-point being able to signal the maximum size of data it is willing /able to accept at a time. This information could be used by the sender to, for example send a less memory intensive version of say an image, instead of a full blown memory hungry version. This will allow the information to be communicated with a decreased risk of truncation at first try. That makes for a more efficient communication (than without this feature). I don't see the need to signal max-send size. So I vote yes/no Cheers, Alex. Adam Roach wrote: >>I don't want to get too deep in this until we have results on >>the "vote" (running neck and neck at the moment.) >> >> > >Put me in the no/no camp. > >/a > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > --------------040805090701050201010103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think there is great value in  end-point being able to signal the maximum size of data it is
willing /able to accept at a time. This information could be used by the sender to, for example
send a less memory intensive version of say an image, instead of a full blown memory hungry
version.  This will allow the information to be communicated with a decreased risk of truncation
at first try. That makes for a more efficient communication (than without this feature).

I don't see the need  to signal max-send size.   So I vote yes/no

Cheers,
Alex.


Adam Roach wrote:
I don't want to get too deep in this until we have results on 
the "vote" (running neck and neck at the moment.)
    

Put me in the no/no camp.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--------------040805090701050201010103-- --===============1703206399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1703206399==-- From simple-bounces@ietf.org Wed Jun 9 18:45:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01566 for ; Wed, 9 Jun 2004 18:45:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYBou-0000d3-Bt for simple-archive@ietf.org; Wed, 09 Jun 2004 18:45:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYBmZ-00072J-00 for simple-archive@ietf.org; Wed, 09 Jun 2004 18:42:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYBhc-00047F-00; Wed, 09 Jun 2004 18:37:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYBb0-0001Oi-L3; Wed, 09 Jun 2004 18:30:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYBT8-0006qb-Se for simple@megatron.ietf.org; Wed, 09 Jun 2004 18:22: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 SAA00473 for ; Wed, 9 Jun 2004 18:22:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYBT7-00005N-E4 for simple@ietf.org; Wed, 09 Jun 2004 18:22:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYBS4-0006vF-00 for simple@ietf.org; Wed, 09 Jun 2004 18:21:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYBQg-00051i-00 for simple@ietf.org; Wed, 09 Jun 2004 18:20:18 -0400 Received: from dynamicsoft.com ([63.113.46.100]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i59MJpbo020731; Wed, 9 Jun 2004 18:19:52 -0400 (EDT) Message-ID: <40C78CE9.6010507@dynamicsoft.com> Date: Wed, 09 Jun 2004 18:19:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> In-Reply-To: <40BCCE85.80508@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > > > Jonathan Rosenberg wrote: > >> The problem here is that a device can host a multiplicity of services >> (my cell phone), each of which may have radically different URI, and >> that a device itself is not well described by a single contact address. > > > I've never been particularly enamored with the notion of devices being > represented as tuples, in the sense of one device = one tuple. Maybe a > better way to look at this is that tuples with contacts are *always* > services. I've come to the conclusion that tuples are always services, period. See more below. From a reachability perspective, as to whether I have three > plastic gadgets on my belt connected by BlueTooth, or whether they are > all in a single Treo-like device or whether they all have a separate > network interfaces seems to matter very little, particularly since (as > was discussed in the interim) it's hard to make very clear delineations > as to what counts as a single device. Just because we can't always be clear as to what's a device, and what's not, doesnt mean that its not useful to say that something is a device. Its useful from a correlation perspective, as you point out below, but I think it acts as a natural conduit for many pieces of information that are inherently about the *device*, and not the service or presentity. Geographic location and device capabilities (screen size, for example) are the most obvious ones. > > The only reason I can see that the notion of a device matters is to > estimate whether two services are pretty much guaranteed to be available > at the same time, by the same person. Yes, correlation is a big part of the need. Its not the only one. > (As opposed to having one service > be left on the dresser at home and one carried by the user.) A simple, > unique and non-reachable identifier that indicates this reachability and > locational unity, as the token, does this. I'd take this one step further, and say that what we want is the ability for a tuple to indicate a multiplicity of , indicating that it runs on those device(s). A device ID is a meaningful identifier, in that it represents an indentifier for that device that other components know about, and would choose to identify the same device. In the case of a cell phone, this might be the ESN for example. > >> >> However, you say something important in your suggestion, which is >> "contact-equipped tuples can be either devices (which also is an >> instance of a service)". My proposal for what "device view" means was >> that you have a tuple that represents all of the services available on >> a particular device, by doing a pivot operation on that device. In >> that way, the service tuple "represents" a device, in that I'm trying >> to have a single tuple for each device. However, the tuple is still >> fundamentally describing a service, NOT a device. > > > We seem to be arriving at similar conclusions through slightly different > paths. My disagreement is that I don't see the possibility of having a > single tuple represent all services on a device, given that, as you say, > they may not have a single reachable protocol URI (sip, mailto, etc.) > that can represent them all. I don't see how > > > urn:device:1234566 > > > helps any, unless we assume that there is a URN resolution mechanism > that actually translates this, ENUM-style, into a set of services. It doesnt. However, if we believe that it should be OK to have a single tuple, and that tuple represents the union of my service characteristics (this is Brian's presentity view), then we have this problem irregardless of whether you like the or not. I would propose that, if you want to indicate availability for communications across a variety of services, and those services can't be represented by a single URI, then you could omit the URI. That is, I think we shouldn't use the presence or absence of the contact URI in the tuple to mean that the tuple is modeling something fundamentally different. Rather, the absence of the contact URI means that the presentity is unable or unwilling to disclose the URI for this service. > > >> >>> >>> Both (1) and (2) can contain RPID and CIPID information (the latter >>> probably only for tuples). If (2) contains RPID >>> information, it means that it refers to the device or service. >> >> >> >> Which? What would it mean when I have devices that support multiple >> services, and a multiplicity of services that can run on a single device? > > > I'd like to determine first what the notion of device is meant to do. Its meant to (1) serve as a way of correlating data together, and (2) act as a container for data that is really about the device. Here's an example of a real problem I have surrounding (1). Lets say I'm able to get some information from the PSTN about the status of a phone - whether its on hook, off-hook, etc. I want to correlate this information (which is associated with the device-ID for the phone), with information about services running on that phone that I learn from PUBLISH, REGISTER, and other means. I can't do this unless the published data from the phone about those services indicates what devices they are on. > > The presence of RPID by itself wouldn't be able to distinguish a service > from a device, thus, it could appear in tuples of both types. Where I'm at is that I think we should have an RPID element called that appears in a tuple, which indicates a device the service runs on. Separately, as a sibling of tuple, the PIDF doc can have elements, which contain the device-id, but also other device-specific data. SO, for example: urn:esn:76533-233374 open im:someone@example.com Germany large little With this, I can have a service that I can say runs on one device or many devices, and if I include the same in multiple tuples, I can indicate that multiple services run on the same device. You can have the without the bigger ; in such a case, it ONLY serves as a correlation tool. This makes the above document play nice with filtering techniques. The "reference" here - the device-ID - has meaning even if the element it talks about disappears from the document. -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-bounces@ietf.org Thu Jun 10 00:58:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20074 for ; Thu, 10 Jun 2004 00:58:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYHdd-0006P8-31 for simple-archive@ietf.org; Thu, 10 Jun 2004 00:58:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYHcj-0005XQ-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 00:57:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYHc8-0004e2-00; Thu, 10 Jun 2004 00:56:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHZE-0004TL-I7; Thu, 10 Jun 2004 00:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHUH-0003sG-P9 for simple@megatron.ietf.org; Thu, 10 Jun 2004 00:48: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 AAA19755 for ; Thu, 10 Jun 2004 00:48:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYHU0-0005L7-4q for simple@ietf.org; Thu, 10 Jun 2004 00:48:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYHSu-0004RU-00 for simple@ietf.org; Thu, 10 Jun 2004 00:47:01 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BYHRf-00031t-00 for simple@ietf.org; Thu, 10 Jun 2004 00:45:43 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5A4jhAh018998 for ; Thu, 10 Jun 2004 06:45:43 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 06:45:43 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Jun 2004 06:45:43 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'alex.audu@alcatel.com'" , Adam Roach Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Thu, 10 Jun 2004 06:45:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-OriginalArrivalTime: 10 Jun 2004 04:45:43.0739 (UTC) FILETIME=[C9EAB8B0:01C44EA5] Cc: pkyzivat@cisco.com, "'hisham.khartabil@nokia.com'" , cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360968610==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1360968610== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44EA5.863A7109" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44EA5.863A7109 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 ONE of the things max-send can be used for, is for the other party to = choose (alone or with whatever other functions and mechanisms) a proper = max-receive value to return. =20 Regards, =20 Christer Holmberg Ericsson Finland -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com] Sent: 9. kes=E4kuuta 2004 23:54 To: Adam Roach Cc: Ben Campbell; Christer Holmberg (JO/LMF); pkyzivat@cisco.com; = 'hisham.khartabil@nokia.com'; cboulton@ubiquity.com; simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max message size indication I think there is great value in end-point being able to signal the = maximum size of data it is willing /able to accept at a time. This information could be used by = the sender to, for example send a less memory intensive version of say an image, instead of a full = blown memory hungry version. This will allow the information to be communicated with a = decreased risk of truncation at first try. That makes for a more efficient communication (than = without this feature).=20 I don't see the need to signal max-send size. So I vote yes/no Cheers, Alex. Adam Roach wrote: I don't want to get too deep in this until we have results on=20 the "vote" (running neck and neck at the moment.) =20 Put me in the no/no camp. /a _______________________________________________ Simple mailing list Simple@ietf.org =20 https://www1.ietf.org/mailman/listinfo/simple = =20 =20 ------_=_NextPart_001_01C44EA5.863A7109 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
ONE of the things max-send can be used for, is for the = other party=20 to choose (alone or with whatever other functions and = mechanisms) a proper=20 max-receive value to return.
 
Regards,
 
Christer Holmberg
Ericsson Finland
-----Original Message-----
From: Alex Audu=20 [mailto:alex.audu@alcatel.com]
Sent: 9. kes=E4kuuta 2004=20 23:54
To: Adam Roach
Cc: Ben Campbell; Christer = Holmberg=20 (JO/LMF); pkyzivat@cisco.com; 'hisham.khartabil@nokia.com';=20 cboulton@ubiquity.com; simple@ietf.org
Subject: Re: = [Simple] Re:=20 MSRP: Max message size indication

I think there = is great=20 value in  end-point being able to signal the maximum size of = data it=20 is
willing /able to accept at a time. This information could be = used by the=20 sender to, for example
send a less memory intensive version of say = an=20 image, instead of a full blown memory hungry
version.  This = will allow=20 the information to be communicated with a decreased risk of = truncation
at=20 first try. That makes for a more efficient communication (than = without this=20 feature).

I don't see the need  to signal max-send=20 size.   So I vote = yes/no

Cheers,
Alex.


Adam=20 Roach wrote:
I don't want to get too =
deep in this until we have results on=20
the "vote" (running neck and neck at the moment.)
    

Put me in the no/no camp.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf=
.org/mailman/listinfo/simple
------_=_NextPart_001_01C44EA5.863A7109-- --===============1360968610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1360968610==-- From simple-bounces@ietf.org Thu Jun 10 01:18:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20783 for ; Thu, 10 Jun 2004 01:18:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYHwz-0007jv-85 for simple-archive@ietf.org; Thu, 10 Jun 2004 01:18:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYHvy-0006ql-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 01:17:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYHuu-000575-00; Thu, 10 Jun 2004 01:15:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHqj-0007zP-Sk; Thu, 10 Jun 2004 01:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHne-00068g-5p for simple@megatron.ietf.org; Thu, 10 Jun 2004 01:08: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 BAA20338 for ; Thu, 10 Jun 2004 01:08:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYHnX-0006Yh-NB for simple@ietf.org; Thu, 10 Jun 2004 01:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYHmW-0005et-00 for simple@ietf.org; Thu, 10 Jun 2004 01:07:17 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BYHlQ-0004lQ-00 for simple@ietf.org; Thu, 10 Jun 2004 01:06:09 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5A569PA008595 for ; Thu, 10 Jun 2004 07:06:09 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 07:06:09 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Jun 2004 07:05:56 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'hisham.khartabil@nokia.com'" , "Gonzalo Camarillo (JO/LMF)" , bcampbell@dynamicsoft.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Thu, 10 Jun 2004 07:05:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Jun 2004 05:06:09.0551 (UTC) FILETIME=[A48EC9F0:01C44EA8] Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, cboulton@ubiquity.com, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I also think it's important to define what you mean by "usable". It's = probably true that from a pure core protocol perspective this is not = needed, but I think I have presented (at least I've tried) cases where = this information can be usable for the user of the protocol, and/or the = protocol stack implementation. Also, I personally don't see this requirment as very "advanced", based = on the fact that since I don't think it doesn't have any impacts on the = core protocol functionality itself. I really would understand if this = is something which could mess up everything we've done so for, or if it = otherwise would take a long time to put into what we've done so far, = but I don't think that is the case. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of hisham.khartabil@nokia.com > Sent: 9. kes=E4kuuta 2004 9:48 > To: Gonzalo Camarillo (JO/LMF); bcampbell@dynamicsoft.com > Cc: jdrosen@dynamicsoft.com; Christer Holmberg (JO/LMF); > cboulton@ubiquity.com; aki.niemi@nokia.com; simple@ietf.org > Subject: RE: [Simple] Re: MSRP: Max message size indication >=20 >=20 > This draft is called "Advanced Instant Messaging Requirements=20 > for the Session Initiation Protocol". Note the word=20 > "Advanced". It means additional, not base requirements. >=20 > We are not at a stage yet where solutions for advanced=20 > requirements can be discussed. The draft is not even a WG=20 > item. There are, however, some exceptions: In some cases, it=20 > was found necessary to incorporate some of the advanced=20 > features to make the protocol usable (eg: DSNs). Max message=20 > size is not one of those. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: 08.June.2004 22:14 > > To: Ben Campbell > > Cc: Niemi Aki (Nokia-M/Espoo); Khartabil Hisham=20 > > (Nokia-TP-MSW/Helsinki); > > Chris Boulton; simple@ietf.org; Christer Holmberg (JO/LMF); = Jonathan > > Rosemberg > > Subject: Re: [Simple] Re: MSRP: Max message size indication > >=20 > >=20 > > Ben, > >=20 > > let me try to understand the discussion here. We have a=20 > requirements=20 > > document (written by Jonathan) that says the following: > >=20 > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes > > saging-requirements-01.txt > >=20 > > "REQ-CONTENT-1: A UA MUST be able to indicate the=20 > maximum message > > size it is willing to receive." > >=20 > > According to the requirements, the protocol MUST support=20 > it... do you=20 > > want to go through the requirements phase again at this point? > >=20 > > Gonzalo > >=20 > >=20 > >=20 > > Ben Campbell wrote: > >=20 > > > So far, I have had 4 people (counting myself) respond=20 > > no/no, 2 respond=20 > > > yes/yes, and one equivocation that I interpret as yes/no. > > >=20 > > > This is a pretty small fraction of the work group. If only=20 > > seven people=20 > > > care enough to even comment, I'm not sure we have a mandate=20 > > for this. > > >=20 > > > So, if there is anyone out there who cares but has not said=20 > > so, please=20 > > > do so soon. > > >=20 > > > Aki Niemi wrote: > > >=20 > > >> I'll have to vote for no/no. I don't think it solves the=20 > > real problem, > > >> which is not having the sender/recipient ability to=20 > abort transfer > > >> mid-message. > > >> > > >> Cheers, > > >> Aki > > >> > > >> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > > >> > > >>> I'd like to try and get some closure on this: > > >>> > > >>> Please answer yes or no to the following: > > >>> > > >>> 1) Should we add the optional signaling of the maximum=20 > > content size=20 > > >>> you are willing to _receive_ into the SDP exchange. > > >>> > > >>> 2) Should we add the optional signaling of the maximum > > content size=20 > > >>> you are planning to _send_ into the SDP exchange. > > >>> > > >>> 3) If either 1 or 2 is yes, do we send one value for the=20 > > session, or=20 > > >>> one value per each type for which we have indicated support. > > >>> > > >>> My personal opinions: > > >>> > > >>> No and No. In all honesty, I think this could be a useful=20 > > feature,=20 > > >>> but I don't think MSRP has to have it to function. I am=20 > > voting no,=20 > > >>> not because I disagree with the feature, but because I=20 > > don't want to=20 > > >>> add additional work to completing MSRP unless it is absolutely=20 > > >>> necessary. But if consensus says we need it, I do not=20 > > object on any=20 > > >>> technical basis. > > >> > >=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-bounces@ietf.org Thu Jun 10 01:32:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21332 for ; Thu, 10 Jun 2004 01:32:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYIAZ-0004YA-DW for simple-archive@ietf.org; Thu, 10 Jun 2004 01:32:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYI9V-0003es-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 01:31:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYI8I-0001uW-00; Thu, 10 Jun 2004 01:29:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYI2W-0001p9-GV; Thu, 10 Jun 2004 01:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHy0-0000xn-3t for simple@megatron.ietf.org; Thu, 10 Jun 2004 01: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 BAA20879 for ; Thu, 10 Jun 2004 01:19:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYHxy-0000pb-4U for simple@ietf.org; Thu, 10 Jun 2004 01:19:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYHx1-0007kE-00 for simple@ietf.org; Thu, 10 Jun 2004 01:18:07 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BYHw0-0006qq-00 for simple@ietf.org; Thu, 10 Jun 2004 01:17:04 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5A5H4PA009538 for ; Thu, 10 Jun 2004 07:17:04 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 07:17:04 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Jun 2004 07:17:04 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'hisham.khartabil@nokia.com'" , "Gonzalo Camarillo (JO/LMF)" , bcampbell@dynamicsoft.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Thu, 10 Jun 2004 07:17:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 10 Jun 2004 05:17:04.0767 (UTC) FILETIME=[2B18D0F0:01C44EAA] Cc: jdrosen@dynamicsoft.com, cboulton@ubiquity.com, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, >This draft is called "Advanced Instant Messaging Requirements >for the Session Initiation Protocol". Note the word >"Advanced". It means additional, not base requirements. > >We are not at a stage yet where solutions for advanced >requirements can be discussed. The draft is not even a WG >item. There are, however, some exceptions: In some cases, it >was found necessary to incorporate some of the advanced >features to make the protocol usable (eg: DSNs). Max message >size is not one of those. During this discussion I think someone indicated that there it could be usable to indicate the max-size in a MSRP 4xx response. Now, to my understanding that is also only an "advanced" requirement - at least I couldn't find it in RFC2779 (please correct me if I'm wrong). Also, a generic question about the IETF procedures. Is it stated somewhere, or has the WG done a check, that we support all appropriate requirements (and which those are) in RFC2779, or is it something someone has to find out for him/herself? Just for my information... Regards, Christer Holmberg Ericsson Finland > > Regards, > Hisham > > > -----Original Message----- > > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: 08.June.2004 22:14 > > To: Ben Campbell > > Cc: Niemi Aki (Nokia-M/Espoo); Khartabil Hisham > > (Nokia-TP-MSW/Helsinki); > > Chris Boulton; simple@ietf.org; Christer Holmberg (JO/LMF); Jonathan > > Rosemberg > > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > > > > Ben, > > > > let me try to understand the discussion here. We have a > requirements > > document (written by Jonathan) that says the following: > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes > > saging-requirements-01.txt > > > > "REQ-CONTENT-1: A UA MUST be able to indicate the > maximum message > > size it is willing to receive." > > > > According to the requirements, the protocol MUST support > it... do you > > want to go through the requirements phase again at this point? > > > > Gonzalo > > > > > > > > Ben Campbell wrote: > > > > > So far, I have had 4 people (counting myself) respond > > no/no, 2 respond > > > yes/yes, and one equivocation that I interpret as yes/no. > > > > > > This is a pretty small fraction of the work group. If only > > seven people > > > care enough to even comment, I'm not sure we have a mandate > > for this. > > > > > > So, if there is anyone out there who cares but has not said > > so, please > > > do so soon. > > > > > > Aki Niemi wrote: > > > > > >> I'll have to vote for no/no. I don't think it solves the > > real problem, > > >> which is not having the sender/recipient ability to > abort transfer > > >> mid-message. > > >> > > >> Cheers, > > >> Aki > > >> > > >> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote: > > >> > > >>> I'd like to try and get some closure on this: > > >>> > > >>> Please answer yes or no to the following: > > >>> > > >>> 1) Should we add the optional signaling of the maximum > > content size > > >>> you are willing to _receive_ into the SDP exchange. > > >>> > > >>> 2) Should we add the optional signaling of the maximum > > content size > > >>> you are planning to _send_ into the SDP exchange. > > >>> > > >>> 3) If either 1 or 2 is yes, do we send one value for the > > session, or > > >>> one value per each type for which we have indicated support. > > >>> > > >>> My personal opinions: > > >>> > > >>> No and No. In all honesty, I think this could be a useful > > feature, > > >>> but I don't think MSRP has to have it to function. I am > > voting no, > > >>> not because I disagree with the feature, but because I > > don't want to > > >>> add additional work to completing MSRP unless it is absolutely > > >>> necessary. But if consensus says we need it, I do not > > object on any > > >>> technical basis. > > >> > > > > > > _______________________________________________ > 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-bounces@ietf.org Thu Jun 10 02:19:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07064 for ; Thu, 10 Jun 2004 02:19:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYIu9-0001e3-N9 for simple-archive@ietf.org; Thu, 10 Jun 2004 02:19:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYIt4-0000jD-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 02:18:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYIrg-0006mo-00; Thu, 10 Jun 2004 02:16:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYIgo-0002GQ-P4; Thu, 10 Jun 2004 02:05:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYIcC-0008IU-PB for simple@megatron.ietf.org; Thu, 10 Jun 2004 02:00: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 CAA23075 for ; Thu, 10 Jun 2004 02:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYIbv-00028P-9F for simple@ietf.org; Thu, 10 Jun 2004 02:00:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYIYC-0007Qr-00 for simple@ietf.org; Thu, 10 Jun 2004 01:56:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYIW1-0005ta-00 for simple@ietf.org; Thu, 10 Jun 2004 01:54:17 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5A5s8bo021001 for ; Thu, 10 Jun 2004 01:54:09 -0400 (EDT) Message-ID: <40C7F761.3000605@dynamicsoft.com> Date: Thu, 10 Jun 2004 01:53:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 2 Interim Summary: Positional Insertions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The issue of positional insertions was discussed during the interim. There was a lot of disagreement on it. There were concerns that it raised the bar too high for implementation complexity. This was tied back into a more general question about our goal here. Is our goal to (1) create a general purpose XML database management protocol, or (2) to create a simple tool for managing the set of documents important to the SIMPLE group. If its (1), then positional insertions make sense, but this is going to be a much larger problem and work item than SIMPLE can/should tackle. There is a lot of work already on XML database protocols that we will have to look at. We discussed the fact that many of the problems that would seem to necessitate positional insertions can be solved with proper schema design. It was also noted that even if you don't design your schema with xcap in mind, xcap will always work, it just may not be as efficient as you might like. There was no consensus on it, but I took an action item to describe the general cases that would appear to motivate the need for positional insertions, and suggest how it can be avoided with other approaches. Furthermore, I took an action to take a look at the current usages (authorization, list management, pidf-manipulation and cpcp) in that context. What follows is a long-ish analysis. If you're not into it, please skip to the conclusions and recommendation at the end, which is to drop positional insertions. So, here were the problem cases I could come up with. There are three of them, problems 1, 2 and 3. In all cases, the problem is the presence of the model in the schema: (Problem 1) The schema includes a sequence of elements, and position of those elements within the parent has semantic significance, for example, some kind of prioritization. Here, if you want to update the document with a new element that has a specific priority, you'd need to put it into the right place. If we don't have positional insertions, you could replace the entire list with each operation. Or, you could design the schema so that it didnt use order as a semantically significant concept. Instead, introduce an attribute that contains the priority. Designing the schema this way has other benefits. It would allow users to insert new elements with a specific priority without having the list in memory. (Problem 2) The schema defines an element A as a sequence of elements X, Y and Z, and the number of each such elements is unbounded. Ordering of each of the elements of the same name is irrelevant, but schema validation requires that all X's come before all Y's which come before all Z's. For example: If there are no positional insertions, there are three solutions. (a) The first is to replace all of A when you want to add a new X, Y or Z. (b) The other is to define the schema so that A is defined as a sequence of X-list, Y-list and Z-list, where there is exactly one of each of these. Within X-list are a sequence of X. Within Y-list are a sqeuence of Y, and within Z-list is a sequence of Z. For example, you would instead do it like this: The reason this works is that the schema mandates that there be exactly one of X-list, Y-list and Z-list. Thus, I never need to *insert* a new X-list, Y-list or Z-list, since they need to appear in the initial document in the first place. So, when I insert a new X with id=3, the URI would be A/X-list/X[@id="3"]. This approach has a side effect, which is an easy way to change all of the X's without requiring the multiple insertions feature. (c) change the schema so that it allows the X, Y and Z in any order. As such, the schema would change from a sequence of X, Y and Z, to a sequence of a choice of X,Y, Z. This is the best solution. (Problem 3) The schema defines A as a sequence of X, Y, and Z, but there are constraints on the number of X, Y and Z. The ordering of the elements has no semantic significance. This case normally arises when X, Y and Z can occur 0 or 1 times, i.e., the represent optional elements. This is the most problematic case. There are several solutions: (a) As in problem 2, solution (a), replace the whole thing (b) As in problem 2, solution (b), define another level in the hierarchy. For the case where the X, Y and Z appear 0 or 1 times, this is pretty inefficient. (c) For elements that can occur 0 or 1 times, redefine the element so that it must always appear, but define a value for it, or an attribute, which effectively indicates its absence. For example, if you want to indicate, in the schema, whether or not feature "foo" is turned on, one could define the element as an empty element, which is present when the feature is on, absent when off. An alternative design that works better with xcap, is to define as always being present, with a value of true or false. To summarize, the schema is problematic when it has element, and that sequence consists of multiple elements of different names which can appear an unbounded number of times, or the sequence has multiple elements of the same name, and the application associates meaning to the order, or the elements in the sequence can appear a variable of times, but bounded in size (ususally 0 or 1 is the most common case of this). These were the only three problematic cases I could identify that motivated the positional insertions. I have done an analysis of the current usages, and here is what I found: resource-list ------------- * Currently, the element is a sequence that starts with and then has a sequence of list. This is problem 2. However, we agreed to remove , and so this won't be an issue. * The entry element is display-name followed by a sequence of elements from other namespaces. This is problem 3. This might be a problem depending on those extensions. If they don't follow the guideliens I describe above, it might require a user to change the entire entry at once. I don't think there is actually anything we can do about it in the schema design; it needs to be described in text as a constraint in extensions. common-policy ------------- * Currently, each is a sequence of 0 or 1 , 0 or 1 , and 0 or 1 . This is problem 3. fix This is problematic if you start with a document that has conditions and actions, and you want to add transformations. The best fix is (a), to require exactly one of these (in fact, I was surprised it didnt work this way). presence-auth ------------- * The element in the inclusion set type is a sequence of rpid elements, each of which can appear an unlimited number of times. Thus, this is problem 2. However, since the ordering is irrelevant, this could be changed to a sequence of choice with no negative consequences. That is, solution c. * The inclusion-set type allows for either a value of , or a sequence of followed by . Currently, there can only be one . Thus, changing this to a sequence of choice would not allow enforcement of this maxOcc restriction. There is, however, no particular reason why there can be only one. If there is more than one, they could just be unioned together. [[In any case I hope we can get rid of inclusion-set for the first pass at the auth policies]] CPCP ---- * The root element, , is a sequence of things (, , etc.). Fortunately, each of these has to appear exactly once. So, they are always in the doc, and there is no need to insert. No problem here. * is a sequence of and then . This is problem 3. If we want to enforce the 0 or 1 constraint on , and we want to allow adding of URI to the list, we have a problem (problem 3). The right fix seems solution (c). Make to occur exactly once, and define a large value as being "unbounded". Then, replace with , which occurs once, and contains a sequence from 0 to unbounded of . * is a sequence of elements, each of which describes some property of the conference. Each can appear 0 or 1 time. This is problem 3. I'm inclined to go for solution A, which is, if you want to change one of these, you need to replace the whole Conference-Info. I dont see them changing much, so it doesnt seem like a big deal. * is a sequence of an optional followed by an optional . Thus, this is problem 3. I'd suggest solution A, replace both if you want to change one of the conference occurences. * The ACL, PCL and DL all work well with xcap, being a sequence of elements of the same name with an unbounded number of them, ordering irrelevant. No problem here. * The element has problem 2, because can appear an unbounded number of times. Recommended solution is solution b, changing to , making that appear only once, and defining its children as a sequence of * Each in has problem 3, and and have problem 3. Since I don't expect this to change much, I suggest solving this with solution A; that is, you update the information for the entire . * In , has problem 3, as in the above case. Here too, solution A seems best. Replace the whole thing. PIDF Manipulation ----------------- * The root element has problem 3. Since the schema cannot be changed, the only solution is solution A. That is, if you want to insert a new tuple or note, you will need to update the whole document. * The element has problem 3. Since the schema cannot be changed, the only solution is solution A. That is, if you want to insert a contact, timestamp or note if there wasnt one before, or add an optional element, you need to replace the whole tuple. * The element has problem 3, but this will be a problem mostly depending on the extensions. Conclusion ----------- The conclusion of my analysis is that: (1) it is possible to document a set of schema design guidelines that can make positional insertions not important for pretty much any application usages, at the expense of (a) eliminating schema validation of the number of counts of an element, (b) increase in document size, or (c) increase in the number of cases in which the parent element needs to be replaced if a child needs to be inserted (2) for the currently defined application usages, the places where insertion is MOST likely to occur commonly are places where there are lists of things (buddy lists, PCLs in CPCP, etc.). Lack of a positional insertion is not a problem here. It is more problematic in cases where there are boolean elements that represent optional information, mostly in CPCP and PIDF. In those two cases, there are workarounds. For CPCP, none of the workarounds seemed bad. PIDF is the biggest problem since the schema can't be changed. I expect that, in most cases, the result is that, if you want to add something (as opposed to changing something), you'll need to replace the parent, be it the whole document or the tuple. However, I dont expect this to happen that often, and the cost penality (more data sent over the network) is relatively small because pidf docs are small. The only real problem is if they should become extremely large (ie., include images). Right now thats not the case. As such, my proposal is to drop positional insertions for this first version, and include them in an extension to be developed downstream. 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-bounces@ietf.org Thu Jun 10 02:33:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08327 for ; Thu, 10 Jun 2004 02:33:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJ7Y-0006VN-4w for simple-archive@ietf.org; Thu, 10 Jun 2004 02:33:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJ6Z-0005bs-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 02:32:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYJ5E-0003ku-00; Thu, 10 Jun 2004 02:30:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYIuJ-0007sU-VW; Thu, 10 Jun 2004 02:19:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYIoT-0004Ow-47 for simple@megatron.ietf.org; Thu, 10 Jun 2004 02:13: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 CAA06325 for ; Thu, 10 Jun 2004 02:13:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYIoB-0004Cj-P5 for simple@ietf.org; Thu, 10 Jun 2004 02:13:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYInB-0003Lt-00 for simple@ietf.org; Thu, 10 Jun 2004 02:12:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYImE-0001ee-00 for simple@ietf.org; Thu, 10 Jun 2004 02:11:02 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5A6Asbo021005 for ; Thu, 10 Jun 2004 02:10:54 -0400 (EDT) Message-ID: <40C7FB4E.3060303@dynamicsoft.com> Date: Thu, 10 Jun 2004 02:10:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 3 Interim Summary: PUT vs. POST X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We had reached consensus on the list that PUT was ok. This was predicated on adopting Jari's proposed approach for handling server assignment of URIs. In that approach, the client first PUTs a document without the URI. Then, the server rejects it, and the response suggests values. The client can then pick one, and retry the request. The second time, it succeeds. There was no disagreement on the usage of PUT, and so I think we are set on that. There was some good discussion on the details of this technique Jari had suggested. One concern was this. In the above proposal, the schema would require the URI to be present. Thus, schema validation would fail, and that would trigger the server to indicate suggested URI in the response. It was pointed out that this is going to be a pain to implement, since you don't want to have to look through a document that failed schema validation, to figure out if it failed because some component was missing. So, it was suggested to make sure it doesnt fail schema validation. The other point, made by Adam, was that there is no point in having the client omit in the URI in the first place. Instead, it should guess something random, and send that. Indeed, the suggestion was made that, if you include a sufficiently random URI, it won't need server assigned URIs at all - the URI will always be unique. However, we do have a requirement for server generated URIs, and this is motivated by vaninty URIs and the desire to control URI assignment within its own namespace. That said, it did make sense to always include a URI anyway, maybe you'll get lucky. So, the conclusion is: (1) we are closed on PUT/POST (2) the URI should always be present, so schema validation will succeed, and the client always suggests something. 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-bounces@ietf.org Thu Jun 10 02:36:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08561 for ; Thu, 10 Jun 2004 02:36:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJAh-0001Lw-Gf for simple-archive@ietf.org; Thu, 10 Jun 2004 02:36:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJ9k-0000TT-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 02:35:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYJ8x-0007Km-00; Thu, 10 Jun 2004 02:34:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYIuz-0008UN-Vv; Thu, 10 Jun 2004 02:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYIs5-0006ca-K0 for simple@megatron.ietf.org; Thu, 10 Jun 2004 02:17: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 CAA06839 for ; Thu, 10 Jun 2004 02:17:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYIs3-0007dm-Bo for simple@ietf.org; Thu, 10 Jun 2004 02:17:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYIr3-0006lM-00 for simple@ietf.org; Thu, 10 Jun 2004 02:16:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYIpn-00053i-00 for simple@ietf.org; Thu, 10 Jun 2004 02:14:43 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5A6EZbo021008 for ; Thu, 10 Jun 2004 02:14:35 -0400 (EDT) Message-ID: <40C7FC2A.5080405@dynamicsoft.com> Date: Thu, 10 Jun 2004 02:14:02 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 4 Interim Summary: document to element separator X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is the micro-issue that won't die. I had proposed the single quote as another choice. However, there was concern that implementors would get this wrong, given the different types of single quotes. It was pointed out that the separator doesnt have to be a single character. So, "~~" was proposed (two tildes). This seemed fine, and there was consensus to use that as the separator. 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-bounces@ietf.org Thu Jun 10 03:26:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09940 for ; Thu, 10 Jun 2004 03:26:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJwv-0004rS-Pa for simple-archive@ietf.org; Thu, 10 Jun 2004 03:26:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJvu-0003z7-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 03:25:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYJum-0002HS-00; Thu, 10 Jun 2004 03:23:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJP9-000846-VA; Thu, 10 Jun 2004 02:51:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJBZ-0005bP-EQ for simple@megatron.ietf.org; Thu, 10 Jun 2004 02:37: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 CAA08588 for ; Thu, 10 Jun 2004 02:37:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJBX-0002Db-AA for simple@ietf.org; Thu, 10 Jun 2004 02:37:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJAR-0001K5-00 for simple@ietf.org; Thu, 10 Jun 2004 02:36:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYJ95-0007O7-00 for simple@ietf.org; Thu, 10 Jun 2004 02:34:39 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5A6YVbo021019 for ; Thu, 10 Jun 2004 02:34:31 -0400 (EDT) Message-ID: <40C800D7.9010104@dynamicsoft.com> Date: Thu, 10 Jun 2004 02:33:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i5A6YVbo021019 Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCAP Issue 5 Interim Summary: selecting multiple elements X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable On the list, we had made some progress in coming up with an algorithm=20 for executing the insertion request as a series of individual=20 insertions. THe key trick was to make sure the entire operation was=20 idempotent. I did some further work during the interim, and found some additional=20 problem cases in the algorithm, notably when you have a mix of ways of=20 selecting an element. I presented this problem case. Lets say you start=20 with this document: and then you do this: PUT http://server/xcap-root/auid/users/joe/foo/bar[@id=3D=931=94]|foo/bar= [3] test Uh oh If you execute each of the two components in order, you get the=20 following document: test Uh oh If you then do the GET back to the same URI: GET http://server/xcap-root/auid/users/joe/foo/bar[@id=3D=931=94]|foo/bar= [3] It returns an error, since foo/bar[@id=3D"1"] now selects multiple=20 elements. Thus, its not idempotent. As such, I proposed two algorithms for the server side algorithm: (1) basically, the server needs to look at the request, and prove=20 idempotency before executing. It will need to check for all of these=20 conditions that could cause the request to not be idempotent. (2) the server keeps a copy of the document before the operation. It=20 then tries the PUT. Once done, it pretends that the client did a GET=20 back to the same URI, and it sees what comes back. If its the same as=20 was in the body of the PUT, the operation was idempotent, and the PUT is=20 accepted. If not, the server goes back to the document before the=20 operation was done, and rejects the PUT request. This can be summarized=20 as "try it and see if it works". Neither seemed particularly compelling, and there was a push from=20 several participants, including myself, to just drop this functionality=20 in this version of the spec. This ties back into the discussion around=20 issue 2 on positional insertions. We discussed the impact on application usages. Hisham identified a=20 problem in CPCP, where you want to add a user to the ACL and PCL at the=20 same time. It was suggested to make a schema change, so that the URI=20 only appears once. The other idea was that, if you were concerned about=20 the latency of doing multiple operations, you could instead pipeline the=20 HTTP PUT operations. So long as you don't need the etag from the=20 previous operation, this would work. Its bandwidth overhead is almost=20 the same as multiple insertions that we've been proposing, and the=20 latency is just about the same thing too. I suggested that I could include some guidelines on schema design to=20 avoid the need for mutliple insertions. There seemed to be support for=20 this position. The guidelines I will include are basically this: (1) if you think you need multiple insertions because you think a common=20 operation will require making two separate changes to the document, try=20 "inverting" the schema so that this doesnt happen. For example, if you ha= ve: and adding requires it to go in and , try doing=20 the schema like this: (2) if you think you need multiple inserts because you want to add=20 multiple entries to a list in one operation, then design the schema to=20 facilitate pipelined PUT. Specifically, make sure that each entry in the=20 list has a unique ID as an attribute, such that no other client is going=20 to choose the same id. Secondly, make sure your schema is such that the=20 path from the document root to this list is "unique". That means that=20 its not possible to change the document such that this path expression=20 remains valid, but points to a different list. This is typically done by=20 making each element in the path mandatory to appear in the document, or=20 if its not mandatory, is identified by a unique attribute that would not=20 be re-assigned. Any objections? Thanks, Jonathan R. --=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 03:27:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09985 for ; Thu, 10 Jun 2004 03:27:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJxq-0005j2-I6 for simple-archive@ietf.org; Thu, 10 Jun 2004 03:27:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJwq-0004qh-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 03:26:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYJvV-00038Q-00; Thu, 10 Jun 2004 03:24:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJYY-0000Rm-Cy; Thu, 10 Jun 2004 03:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJJV-0006mf-Te for simple@megatron.ietf.org; Thu, 10 Jun 2004 02:45: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 CAA08864 for ; Thu, 10 Jun 2004 02:45:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJJE-0001Nh-Hs for simple@ietf.org; Thu, 10 Jun 2004 02:45:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJID-0000WN-00 for simple@ietf.org; Thu, 10 Jun 2004 02:44:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYJHH-0006dl-00 for simple@ietf.org; Thu, 10 Jun 2004 02:43:08 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5A6gxbo021022 for ; Thu, 10 Jun 2004 02:42:59 -0400 (EDT) Message-ID: <40C802D3.20305@dynamicsoft.com> Date: Thu, 10 Jun 2004 02:42:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 6 Interim Summary: selecting elements by text value X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The issue here was whether or not to include a feature in xcap that allowed you to select an element by the value of its content. For example, if the doc is this: val ue then you could do foo/bar[.="val"] and this would select the first bar element. The problem, raised by Joel on the list and discussed at the meeting, is that this makes sense only if the text content is actually a useful index. In some application usages, the text content may be text for human consumption, like a paragraph of text (think about the element in xml2rfc). Indexing this is expensive and a waste of time. I proposed three possible solutions: 1. add more complexity to the spec - allow applicaiton usages to declare, in their definitions, when text content represents an index. An implementation would therefore be able to be dynamically programmed to know which element content to index. 2. Allow selection of elements based on content; assume that URIs would not use content as a selector unless it really was a useful index 3. do not allow selection based on content The question was raised as to whether there was a specific application usage driving this feature. There isn't. There was general agreement to only add stuff if a concrete need in an existing application usage was driving it. Since it was not the case here, there was consensus to drop this feature. Any objections? 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-bounces@ietf.org Thu Jun 10 03:38:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10427 for ; Thu, 10 Jun 2004 03:38:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYK8V-0007UX-JB for simple-archive@ietf.org; Thu, 10 Jun 2004 03:38:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYK7W-0006c3-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 03:37:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYK6G-0004sC-00; Thu, 10 Jun 2004 03:35:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJuz-0003ev-MK; Thu, 10 Jun 2004 03:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYJmW-000119-Kx for simple@megatron.ietf.org; Thu, 10 Jun 2004 03:15: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 DAA09768 for ; Thu, 10 Jun 2004 03:15:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYJmF-0003FU-E7 for simple@ietf.org; Thu, 10 Jun 2004 03:15:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYJlF-0002Nq-00 for simple@ietf.org; Thu, 10 Jun 2004 03:14:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYJk5-0000gC-00 for simple@ietf.org; Thu, 10 Jun 2004 03:12:53 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5A7Cjbo021041 for ; Thu, 10 Jun 2004 03:12:45 -0400 (EDT) Message-ID: <40C809CD.80003@dynamicsoft.com> Date: Thu, 10 Jun 2004 03:12:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 7 Interim Summary: uniqueness in intermediate hops X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is an issue raised by Joel and discussed on the list. The problem was whether or not we would require the URI to select a unique element at each hop of its evaluation, or just make sure the final result of selection was unique. If you are implementing XCAP without an XPATH library, this is a really nice feature to have. There is code and computational complexity if its not there. If you have an XPATH library, its a constraint that you need to explicitly verify outside of the xpath library, since XPATH does allow non-uniqueness at each hop. There were continuing objections to the complexity introduced if each hop is not unique. As such, there was consensus on the uniqueness requirement. However, Henning had a proposal to take this a step further. His proposal was that we could constrain XCAP so that at each step, you were selecting an element based on a unique index that was declared by the application usage to be unique. This way, you couldn't even ever have an expression which selected multiple things at each step. Here's an example to explain. Lets say we've got a schema that has a parent element called , and can have one or more children, each named . So, the following is a valid document: And thus, the expression "foo/bar" selects the element, and also gives you a single element at each step. Thus, it would be valid. However, in Hennings proposal, this expression would be illegal, since it might be the case that is not unique, and thus it could be the case that tbe expression "foo/bar" does not resolve to something unique. In such a case, the schema would have to mandate that each bar element have an attribute called "id" (for example), and that the application usage would mandate that this attribute be unique amongst all siblings. If you do that, then you can be guaranteed that the expression: foo/bar[@id="223"] is unique. It may not point to anything, but if it does, it points to only one element. Henning, if I have mis-interpreted your proposal, let me know. This proposal was further refined. The idea was that an element needs to have a unique index only if it can appear more than once in the document. If it can appear only once, you don't need to define a unique attribute for it. Upon further consideration, I concluded that the refined proposal was not a good idea. The objective of what Henning was proposing is that a server could look at the URI, and without needing to know the schema or even the instance document, determine whether the URI resolved to something unique. Of course, it could still resolve to nothing if any one of the indices didn't exist in the instance document. With the refined proposal, the server would need to know the schema to determine whether the URI was unique. That adds a lot of complexity; you'd need to plug some kind of meta-data about the schema into the xcap server, so it could figure out which elements were unique in the document, and which weren't. Thus, it would add more complexity than it would remove. Indeed, for Henning's proposal to work, you'd need every schema to have the same attribute name as a unique index. For example, "id". We'd have to mandate that every document managed by XCAP, for each element in that document, have an attribute called "id" that's present in the doc, so we can use it as an index and guarantee its always there. That eliminates the possibility of xcap managing existing documents (for example, PIDF). I think that is a costly result. Furthermore, you STILL need to parse through the document to determine if the URI points to something or nothing. Once you've committed to doing that, the additional cost of doing a dynamic check for unqiueness seems trivial to me. Thus, I'd propose that we stick with our original conclusion, which is to mandate that the XCAP expression evaluate to a unique element at each step. This constraint would be checked by the server dynamically based on the instance document. Objections? -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-bounces@ietf.org Thu Jun 10 04:33:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12087 for ; Thu, 10 Jun 2004 04:33:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYKzl-0001E9-O2 for simple-archive@ietf.org; Thu, 10 Jun 2004 04:33:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYKym-0000KZ-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 04:32:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYKxS-0006Os-00; Thu, 10 Jun 2004 04:30:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYKjT-0004RQ-68; Thu, 10 Jun 2004 04:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYKdf-0003H0-5x for simple@megatron.ietf.org; Thu, 10 Jun 2004 04:10: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 EAA11462 for ; Thu, 10 Jun 2004 04:10:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYKda-0004PQ-Mf for simple@ietf.org; Thu, 10 Jun 2004 04:10:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYKcv-0003WZ-00 for simple@ietf.org; Thu, 10 Jun 2004 04:09:34 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BYKaf-000117-00 for simple@ietf.org; Thu, 10 Jun 2004 04:07:13 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i5A86aLc005240; Thu, 10 Jun 2004 03:06:36 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.157]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB8Y592; Thu, 10 Jun 2004 03:06:06 -0500 Message-ID: <40C81689.207@ericsson.com> Date: Thu, 10 Jun 2004 11:06:33 +0300 X-Sybari-Trust: 32865f55 100f6658 5e74f24e 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: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] Re: MSRP: Max message size indication References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, "'hisham.khartabil@nokia.com'" , simple@ietf.org, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, we are using more time in discussing this small issue than what it would take to resolve it. People are asking for an *optional* SDP attribute that allows a UA to say "Hey, FYI: I cannot receive messages over 40 KB". Writing the specification of such an SDP attribute would take, literally, less than 10 minutes, because you do not need any type of negotiation or any type of special offer/answer behavior. It is only an attribute that is sent to the receiver of the SDP "For His Information". If the receiver does not understand it, nothing bad happens. Some people have claimed that the addition of such attribute could delay the standardization of the protocol (I have not heard any technical reason against this parameter)... given that it is only an *optional* informational attribute that can be defined in a couple of paragraphs, its inclusion would not delay the protocol at all. So, if nobody has a better reason for excluding this attribute that claiming that it would delay things, I propose that we add its definition to MSRP and move on to issues that do have a real impact in the MSRP protocol machinery. Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 05:07:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13584 for ; Thu, 10 Jun 2004 05:07:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYLWW-0006vo-2H for simple-archive@ietf.org; Thu, 10 Jun 2004 05:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYLTs-00059x-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 05:04:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYLQa-0002wX-00; Thu, 10 Jun 2004 05:00:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYLEH-0002o8-PL; Thu, 10 Jun 2004 04:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYLBa-0001js-KB for simple@megatron.ietf.org; Thu, 10 Jun 2004 04:45: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 EAA12714 for ; Thu, 10 Jun 2004 04:45:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYLBV-0004RU-Hs for simple@ietf.org; Thu, 10 Jun 2004 04:45:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYLAa-0003V5-00 for simple@ietf.org; Thu, 10 Jun 2004 04:44:22 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BYL9o-0002ZJ-00 for simple@ietf.org; Thu, 10 Jun 2004 04:43:32 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5A8hUx08854; Thu, 10 Jun 2004 11:43:30 +0300 (EET DST) X-Scanned: Thu, 10 Jun 2004 11:43:19 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5A8hJwh019801; Thu, 10 Jun 2004 11:43:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00wLEvAx; Thu, 10 Jun 2004 11:43:17 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5A8hGH00522; Thu, 10 Jun 2004 11:43:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Jun 2004 11:43:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Jun 2004 11:43:16 +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] XCAP Issue 2 Interim Summary: Positional Insertions Date: Thu, 10 Jun 2004 11:43:15 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C38@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions Thread-Index: AcROsqEwGAuxxcdHTIOGqY6LLEPVKgAEtV3Q To: , X-OriginalArrivalTime: 10 Jun 2004 08:43:16.0552 (UTC) FILETIME=[F9416480:01C44EC6] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jonathan, Thanks for the analysis. Reading your analysis actually brings me to the opposite conclusion to = the one you made. That is, we need positional insertions. There are so = many rules, restriction, and guide lines that need to be educated to = current and future designers of XCAP friendly schemas. Wouldn't it be a = much better investment if we allow positional insertions now and avoid = schema misdesign? You haven't explicitly listed the issues with positional insertions, but = instead you listed the problems that it solves. Can you please educate = the rest of us what the real problems are with positional insertions? Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 10.June.2004 08:54 > To: Simple WG > Subject: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions >=20 >=20 > The issue of positional insertions was discussed during the interim. > There was a lot of disagreement on it. There were concerns that it > raised the bar too high for implementation complexity. This was tied > back into a more general question about our goal here. Is our goal to > (1) create a general purpose XML database management=20 > protocol, or (2) to > create a simple tool for managing the set of documents=20 > important to the > SIMPLE group. If its (1), then positional insertions make sense, but > this is going to be a much larger problem and work item than SIMPLE > can/should tackle. There is a lot of work already on XML database > protocols that we will have to look at. >=20 > We discussed the fact that many of the problems that would seem to > necessitate positional insertions can be solved with proper > schema design. It was also noted that even if > you don't design your schema with xcap in mind, xcap will always work, > it just may not be as efficient as you might like. >=20 > There was no consensus on it, but I took an action item to=20 > describe the > general cases that would appear to motivate the need for positional > insertions, and suggest how it can be avoided with other approaches. > Furthermore, I took an action to take a look at the current usages > (authorization, list management, pidf-manipulation and cpcp) in that > context. >=20 > What follows is a long-ish analysis. If you're not into it,=20 > please skip=20 > to the conclusions and recommendation at the end, which is to drop=20 > positional insertions. >=20 >=20 >=20 > So, here were the problem cases I could come up with. There=20 > are three of=20 > them, problems 1, 2 and 3. In all cases, the problem is the=20 > presence of=20 > the model in the schema: >=20 > (Problem 1) The schema includes a sequence of elements, and=20 > position of=20 > those > elements within the parent has semantic significance, for=20 > example, some > kind of prioritization. Here, if you want to update the=20 > document with a > new element that has a specific priority, you'd need to put=20 > it into the > right place. >=20 > If we don't have positional insertions, you could replace the entire > list with each operation. Or, you could design the schema so that it > didnt use order as a semantically significant concept. Instead, > introduce an attribute that contains the priority. Designing=20 > the schema > this way has other benefits. It would allow users to insert=20 > new elements > with a specific priority without having the list in memory. >=20 > (Problem 2) The schema defines an element A as a sequence of=20 > elements X,=20 > Y and > Z, and the number of each such elements is unbounded.=20 > Ordering of each of > the elements of the same name is irrelevant, but schema validation > requires that all X's come before all Y's which come before=20 > all Z's. For > example: >=20 > > > > > > >=20 >=20 > If there are no positional insertions, there are three solutions. >=20 > (a) The first is to replace all of A when you want to add a=20 > new X, Y or Z. >=20 > (b) The other is to define the schema so that A is defined as=20 > a sequence > of X-list, Y-list and Z-list, where there is exactly one of each of > these. Within X-list are a sequence of X. Within Y-list are a sqeuence > of Y, and within Z-list is a sequence of Z. For example, you would > instead do it like this: >=20 > > > > > > > > > > > > >=20 > The reason this works is that the schema mandates that there=20 > be exactly > one of X-list, Y-list and Z-list. Thus, I never need to *insert* a new > X-list, Y-list or Z-list, since they need to appear in the initial > document in the first place. So, when I insert a new X with id=3D3, = the > URI would be A/X-list/X[@id=3D"3"]. This approach has a side=20 > effect, which > is an easy way to change all of the X's without requiring the multiple > insertions feature. >=20 > (c) change the schema so that it allows the X, Y and Z in any=20 > order. As > such, the schema would change from a sequence of X, Y and Z, to a > sequence of a choice of X,Y, Z. This is the best solution. >=20 >=20 > (Problem 3) The schema defines A as a sequence of X, Y, and=20 > Z, but there=20 > are constraints on the number of X, Y and Z. The ordering of the=20 > elements has no semantic significance. This case normally=20 > arises when X,=20 > Y and Z can occur 0 or 1 times, i.e., the represent optional elements. >=20 >=20 > This is the most problematic case. There are several solutions: >=20 > (a) As in problem 2, solution (a), replace the whole thing >=20 > (b) As in problem 2, solution (b), define another level in the=20 > hierarchy. For the case where the X, Y and Z appear 0 or 1=20 > times, this=20 > is pretty inefficient. >=20 > (c) For elements that can occur 0 or 1 times, redefine the element so=20 > that it must always appear, but define a value for it, or an=20 > attribute,=20 > which effectively indicates its absence. For example, if you want to=20 > indicate, in the schema, whether or not feature "foo" is=20 > turned on, one=20 > could define the element as an empty element, which is present=20 > when the feature is on, absent when off. An alternative design that=20 > works better with xcap, is to define as always being=20 > present, with=20 > a value of true or false. >=20 >=20 >=20 > To summarize, the schema is problematic when it has=20 > element, > and that sequence consists of multiple elements of different=20 > names which > can appear an unbounded number of times, or the sequence has multiple > elements of the same name, and the application associates=20 > meaning to the > order, or the elements in the sequence can appear a variable=20 > of times,=20 > but bounded in size (ususally 0 or 1 is the most common case of this). >=20 > These were the only three problematic cases I could identify that > motivated the positional insertions. >=20 > I have done an analysis of the current usages, and here is=20 > what I found: >=20 > resource-list > ------------- >=20 > * Currently, the element is a sequence that=20 > starts with > and then has a sequence of list. This is problem 2.=20 > However, we agreed to remove , and so this=20 > won't be an issue. >=20 > * The entry element is display-name followed by a sequence of elements > from other namespaces. This is problem 3. This might be a problem=20 > depending on those > extensions. If they don't follow the guideliens I describe above, it > might require a user to change the entire entry at once. I don't think > there is actually anything we can do about it in the schema design; it > needs to be described in text as a constraint in extensions. >=20 > common-policy > ------------- >=20 > * Currently, each is a sequence of 0 or 1 , 0 or 1 > , and 0 or 1 . This is problem 3.=20 > fix This is=20 > problematic if you > start with a document that has conditions and actions, and you want to > add transformations. The best fix is (a), to require exactly one of=20 > these (in > fact, I was surprised it didnt work this way). >=20 > presence-auth > ------------- >=20 > * The element in the inclusion set type is a=20 > sequence of=20 > rpid elements, each of which can appear an unlimited number of times.=20 > Thus, this is problem 2. However, since the ordering is=20 > irrelevant, this=20 > could be changed to a sequence of choice with no negative=20 > consequences.=20 > That is, solution c. >=20 > * The inclusion-set type allows for either a value of=20 > , or a=20 > sequence of followed by .=20 > Currently, there=20 > can only be one . Thus, changing this to a sequence of=20 > choice would not allow enforcement of this maxOcc=20 > restriction. There is,=20 > however, no particular reason why there can be only one. If there is=20 > more than one, they could just be unioned together. [[In any=20 > case I hope=20 > we can get rid of inclusion-set for the first pass at the=20 > auth policies]] >=20 > CPCP > ---- >=20 > * The root element, , is a sequence of things=20 > (, , etc.).=20 > Fortunately, each of=20 > these has to appear exactly once. So, they are always in the doc, and=20 > there is no need to insert. No problem here. >=20 > * is a sequence of and then=20 > . This is problem 3. If we want to=20 > enforce the 0=20 > or 1 constraint on , and we want to=20 > allow adding=20 > of URI to the list, we have a problem=20 > (problem 3). The=20 > right fix seems solution (c). Make to occur=20 > exactly once, and define a large value as being "unbounded". Then,=20 > replace with , which occurs=20 > once, and=20 > contains a sequence from 0 to unbounded of . >=20 > * is a sequence of elements, each of which=20 > describes=20 > some property of the conference. Each can appear 0 or 1 time. This is=20 > problem 3. I'm inclined to go for solution A, which is, if=20 > you want to=20 > change one of these, you need to replace the whole Conference-Info. I=20 > dont see them changing much, so it doesnt seem like a big deal. >=20 > * is a sequence of an optional =20 > followed by an optional . Thus, this is problem 3. I'd=20 > suggest solution A, replace both if you want to change one of the=20 > conference occurences. >=20 > * The ACL, PCL and DL all work well with xcap, being a sequence of=20 > elements of the same name with an unbounded number of them, ordering=20 > irrelevant. No problem here. >=20 > * The element has problem 2, because can appear an=20 > unbounded number of times. Recommended solution is solution=20 > b, changing=20 > to , making that appear only once,=20 > and defining=20 > its children as a sequence of >=20 > * Each in has problem 3, and=20 > and have problem 3. Since I don't=20 > expect this=20 > to change much, I suggest solving this with solution A; that is, you=20 > update the information for the entire . >=20 > * In , has problem 3, as in the=20 > above case.=20 > Here too, solution A seems best. Replace the whole thing. >=20 >=20 > PIDF Manipulation > ----------------- >=20 > * The root element has problem 3. Since the schema=20 > cannot be=20 > changed, the only solution is solution A. That is, if you=20 > want to insert=20 > a new tuple or note, you will need to update the whole document. >=20 > * The element has problem 3. Since the schema cannot=20 > be changed,=20 > the only solution is solution A. That is, if you want to insert a=20 > contact, timestamp or note if there wasnt one before, or add=20 > an optional=20 > element, you need to replace the whole tuple. >=20 > * The element has problem 3, but this will be a=20 > problem mostly=20 > depending on the extensions. >=20 >=20 >=20 > Conclusion > ----------- >=20 > The conclusion of my analysis is that: >=20 > (1) it is possible to document a set of schema design=20 > guidelines that=20 > can make positional insertions not important for pretty much any=20 > application usages, at the expense of (a) eliminating schema=20 > validation=20 > of the number of counts of an element, (b) increase in=20 > document size, or=20 > (c) increase in the number of cases in which the parent=20 > element needs to=20 > be replaced if a child needs to be inserted >=20 > (2) for the currently defined application usages, the places where=20 > insertion is MOST likely to occur commonly are places where there are=20 > lists of things (buddy lists, PCLs in CPCP, etc.). Lack of a=20 > positional=20 > insertion is not a problem here. It is more problematic in=20 > cases where=20 > there are boolean elements that represent optional=20 > information, mostly=20 > in CPCP and PIDF. In those two cases, there are workarounds.=20 > For CPCP,=20 > none of the workarounds seemed bad. PIDF is the biggest problem since=20 > the schema can't be changed. I expect that, in most cases,=20 > the result is=20 > that, if you want to add something (as opposed to changing=20 > something),=20 > you'll need to replace the parent, be it the whole document or the=20 > tuple. However, I dont expect this to happen that often, and the cost=20 > penality (more data sent over the network) is relatively=20 > small because=20 > pidf docs are small. The only real problem is if they should become=20 > extremely large (ie., include images). Right now thats not the case. >=20 >=20 > As such, my proposal is to drop positional insertions for this first=20 > version, and include them in an extension to be developed downstream. >=20 > Thanks, > Jonathan R. >=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 >=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-bounces@ietf.org Thu Jun 10 05:23:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14540 for ; Thu, 10 Jun 2004 05:23:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYLmr-00065t-NU for simple-archive@ietf.org; Thu, 10 Jun 2004 05:23:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYLlA-0004Kk-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 05:22:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYLjS-00034a-00; Thu, 10 Jun 2004 05:20:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYLUl-0005zN-Nt; Thu, 10 Jun 2004 05:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYLP3-0004py-Th for simple@megatron.ietf.org; Thu, 10 Jun 2004 04: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 EAA13064 for ; Thu, 10 Jun 2004 04:59:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYLP1-0001zH-9d for simple@ietf.org; Thu, 10 Jun 2004 04:59:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYLNz-000128-00 for simple@ietf.org; Thu, 10 Jun 2004 04:58:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BYLMn-0007Ra-00 for simple@ietf.org; Thu, 10 Jun 2004 04:56:58 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5A8ujx25365; Thu, 10 Jun 2004 11:56:46 +0300 (EET DST) X-Scanned: Thu, 10 Jun 2004 11:56:26 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5A8uQHV032263; Thu, 10 Jun 2004 11:56:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00kNQ8fk; Thu, 10 Jun 2004 11:56:25 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5A8uJH28844; Thu, 10 Jun 2004 11:56:19 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Jun 2004 11:56:18 +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] Re: MSRP: Max message size indication Date: Thu, 10 Jun 2004 11:56:18 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C3A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: MSRP: Max message size indication Thread-Index: AcROwl0JzoQ2XakWRBWqigxUZg/CAAABVMOQ To: , X-OriginalArrivalTime: 10 Jun 2004 08:56:18.0718 (UTC) FILETIME=[CB7673E0:01C44EC8] Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, simple@ietf.org, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Gonzalo, We need to be sure that this feature is useful. It is definitely a nice = to have and not a must feature. I have posted a list of questions that = need answering in an earlier email. We also need to provide guidelines = on how to create this value, what it can be used for and how useful it = is. I am not yet convinced that it is useful unless you mandate the = message sender to obey it and indicate how the value can be generated. Of course we need time to discuss its usefulness. Solving it is not an = issue. /Hisham > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 10.June.2004 11:07 > To: Christer Holmberg (JO/LMF) > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > bcampbell@dynamicsoft.com; > jdrosen@dynamicsoft.com; cboulton@ubiquity.com; Niemi Aki > (Nokia-M/Espoo); simple@ietf.org > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 > Folks, >=20 > we are using more time in discussing this small issue than=20 > what it would=20 > take to resolve it. People are asking for an *optional* SDP attribute=20 > that allows a UA to say "Hey, FYI: I cannot receive messages=20 > over 40 KB". >=20 > Writing the specification of such an SDP attribute would take,=20 > literally, less than 10 minutes, because you do not need any type of=20 > negotiation or any type of special offer/answer behavior. It=20 > is only an=20 > attribute that is sent to the receiver of the SDP "For His=20 > Information".=20 > If the receiver does not understand it, nothing bad happens. >=20 > Some people have claimed that the addition of such attribute=20 > could delay=20 > the standardization of the protocol (I have not heard any technical=20 > reason against this parameter)... given that it is only an *optional*=20 > informational attribute that can be defined in a couple of=20 > paragraphs,=20 > its inclusion would not delay the protocol at all. >=20 > So, if nobody has a better reason for excluding this attribute that=20 > claiming that it would delay things, I propose that we add its=20 > definition to MSRP and move on to issues that do have a real=20 > impact in=20 > the MSRP protocol machinery. >=20 > Gonzalo >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 05:47:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15557 for ; Thu, 10 Jun 2004 05:47:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYM9e-0004KE-EC for simple-archive@ietf.org; Thu, 10 Jun 2004 05:47:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYM8U-0003LO-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 05:46:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYM7E-0001Te-00; Thu, 10 Jun 2004 05:44:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYLxm-0004Po-CR; Thu, 10 Jun 2004 05:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYLt6-00037M-4T for simple@megatron.ietf.org; Thu, 10 Jun 2004 05: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 FAA14824 for ; Thu, 10 Jun 2004 05:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYLt3-0004lz-Ie for simple@ietf.org; Thu, 10 Jun 2004 05:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYLs5-0003pa-00 for simple@ietf.org; Thu, 10 Jun 2004 05:29:18 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BYLql-0001xh-00 for simple@ietf.org; Thu, 10 Jun 2004 05:27:55 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i5A9RLLc017529; Thu, 10 Jun 2004 04:27:21 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.157]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB8ZAB8; Thu, 10 Jun 2004 04:26:51 -0500 Message-ID: <40C82976.5010406@ericsson.com> Date: Thu, 10 Jun 2004 12:27:18 +0300 X-Sybari-Trust: 9917de6e 100f6658 5e74f24e 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: hisham.khartabil@nokia.com Subject: Re: [Simple] Re: MSRP: Max message size indication References: <2038BCC78B1AD641891A0D1AE133DBB701797C3A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C3A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org, christer.holmberg@ericsson.com, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hisham, > We need to be sure that this feature is useful. It is definitely a > nice to have and not a must feature. A bunch of people have said that they need this feature. So, we are talking about a feature whose complexity is negligible, that is needed by some people, that would take 10 minutes to specify, and that, if you do not need it, you just don't implement it... really, what is the problem?? > I have posted a list of > questions that need answering in an earlier email. We also need to > provide guidelines on how to create this value, You create this value based on your device's limitations (i.e., up to local policy). > what it can be used > for If an entity understands this attribute, it SHOULD NOT send messages bigger that what the attribute says to the remote end. > and how useful it is. > > I am not yet convinced that it is useful > unless you mandate the message sender to obey it and indicate how the > value can be generated. I guess you are having problems understanding the optionality of the attribute. Let me give you an example. My SIP device does not support video. So, my presence information says that I am available on a device that only supports audio. If you want to call me, your terminal fetches my presence information, and does not even try to offer me video. If directly invites me to an audio-only session. Now, since implementing presence in a device is optional, you may have a SIP UA which does not support it. If you try to call me from that device, you will invite me to a video session... since we know that presence is an optional feature, my terminal is ready to reject your video stream. That is, we have a rejection mechanism in place. Exactly the same thing as with the max-rev attribute. If you understand the attribute, you wouldn't even try to send me big messages. If you do not understand it (because it is optional and you did not want to implement it), you will send me big messages, and I will reject them using the rejection mechanism. Not optimal, but still works. This is the meaning of optional here. > Of course we need time to discuss its usefulness. Solving it is not > an issue. Again, if this is useful to a bunch of people, and the rest do not need to worry about it, we should go for it and move on. Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 06:35:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17641 for ; Thu, 10 Jun 2004 06:35:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYMu6-0007UW-Lw for simple-archive@ietf.org; Thu, 10 Jun 2004 06:35:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYMt6-0006Yc-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 06:34:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYMsT-0005ay-00; Thu, 10 Jun 2004 06:33:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYMkF-0003tg-C4; Thu, 10 Jun 2004 06:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYMjB-00034i-BE for simple@megatron.ietf.org; Thu, 10 Jun 2004 06:24: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 GAA16910 for ; Thu, 10 Jun 2004 06:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYMj7-0004rG-Qb for simple@ietf.org; Thu, 10 Jun 2004 06:24:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYMgd-00031h-00 for simple@ietf.org; Thu, 10 Jun 2004 06:21:32 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BYMfi-00024Z-00 for simple@ietf.org; Thu, 10 Jun 2004 06:20:34 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5AAKZWR006729 for ; Thu, 10 Jun 2004 12:20:35 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 12:20:35 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L79QDH5N; Thu, 10 Jun 2004 12:20:35 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jun 2004 12:20:35 +0200 Message-ID: <6F936E2F8E16234BA8D88B2EE8338332265131@esealnt912.al.sw.ericsson.se> X-Sybari-Trust: e2a722a3 100f6658 5e74f24e 00000138 From: "Atle Monrad (GR/ETO)" To: "'hisham.khartabil@nokia.com'" , "Gonzalo Camarillo (JO/LMF)" , "Christer Holmberg (JO/LMF)" Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Thu, 10 Jun 2004 12:20:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Jun 2004 10:20:35.0175 (UTC) FILETIME=[91588F70:01C44ED4] Cc: jdrosen@dynamicsoft.com, cboulton@ubiquity.com, simple@ietf.org, aki.niemi@nokia.com, bcampbell@dynamicsoft.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi As we provides SW to multiple terminal manufacturers within 3gpp, we se a benefit with flexibility within the MSRP protocol. The messaging applications are likely to vary, depending on the ideas of e.g. application developers, network models (intermediaries or not) and charging models. 1. We would like the possibility to reject an incoming message as soon as we realise it's over the acceptable size limit. 2. We would like the possibility to give recommentations from the receiving handset on how big messages the handset want/can receive. From this point of view, I'm in at least in the the yes/no camp, even if max-send may be useful in certain cases. Definitely, yes/yes is better than no/no ;-) When you inform the peer entity about the max size of the message you want to receive, that may be useful information to the sender, as he knows that you most likely will reject a longer message, thus he shouldn't attempt to send it. I do not see a need for lots of text around this. In particular, I do not think possible algorithms describing the background of how the sender came up with the max-send figure is needed at all. Just go for a minimum text outlining the SDP-attribute. /atle monrad Ericsson Mobile Platform -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf Of hisham.khartabil@nokia.com Sent: 10. juni 2004 10:56 To: Gonzalo Camarillo (JO/LMF); Christer Holmberg (JO/LMF) Cc: jdrosen@dynamicsoft.com; simple@ietf.org; cboulton@ubiquity.com; bcampbell@dynamicsoft.com; aki.niemi@nokia.com Subject: RE: [Simple] Re: MSRP: Max message size indication Gonzalo, We need to be sure that this feature is useful. It is definitely a nice to have and not a must feature. I have posted a list of questions that need answering in an earlier email. We also need to provide guidelines on how to create this value, what it can be used for and how useful it is. I am not yet convinced that it is useful unless you mandate the message sender to obey it and indicate how the value can be generated. Of course we need time to discuss its usefulness. Solving it is not an issue. /Hisham > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 10.June.2004 11:07 > To: Christer Holmberg (JO/LMF) > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); > bcampbell@dynamicsoft.com; > jdrosen@dynamicsoft.com; cboulton@ubiquity.com; Niemi Aki > (Nokia-M/Espoo); simple@ietf.org > Subject: Re: [Simple] Re: MSRP: Max message size indication > > > Folks, > > we are using more time in discussing this small issue than > what it would > take to resolve it. People are asking for an *optional* SDP attribute > that allows a UA to say "Hey, FYI: I cannot receive messages > over 40 KB". > > Writing the specification of such an SDP attribute would take, > literally, less than 10 minutes, because you do not need any type of > negotiation or any type of special offer/answer behavior. It > is only an > attribute that is sent to the receiver of the SDP "For His > Information". > If the receiver does not understand it, nothing bad happens. > > Some people have claimed that the addition of such attribute > could delay > the standardization of the protocol (I have not heard any technical > reason against this parameter)... given that it is only an *optional* > informational attribute that can be defined in a couple of > paragraphs, > its inclusion would not delay the protocol at all. > > So, if nobody has a better reason for excluding this attribute that > claiming that it would delay things, I propose that we add its > definition to MSRP and move on to issues that do have a real > impact in > the MSRP protocol machinery. > > Gonzalo > > > _______________________________________________ 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-bounces@ietf.org Thu Jun 10 08:51:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29947 for ; Thu, 10 Jun 2004 08:51:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYP26-0003H5-VQ for simple-archive@ietf.org; Thu, 10 Jun 2004 08:51:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYP0u-0002hd-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 08:50:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYOzZ-00029e-02; Thu, 10 Jun 2004 08:49:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYOpf-00063q-G0; Thu, 10 Jun 2004 08:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYOkv-0002LI-Kg; Thu, 10 Jun 2004 08:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYOcK-0000al-4Q for simple@megatron.ietf.org; Thu, 10 Jun 2004 08:25: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 IAA28405 for ; Thu, 10 Jun 2004 08:25:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYOcJ-0005vs-Gi for simple@ietf.org; Thu, 10 Jun 2004 08:25:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYObS-0005Tr-00 for simple@ietf.org; Thu, 10 Jun 2004 08:24:19 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BYOae-00051E-00 for simple@ietf.org; Thu, 10 Jun 2004 08:23:28 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ACNOd14612; Thu, 10 Jun 2004 15:23:24 +0300 (EET DST) X-Scanned: Thu, 10 Jun 2004 15:23:13 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5ACNDVH021750; Thu, 10 Jun 2004 15:23:13 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00YSw59S; Thu, 10 Jun 2004 15:23:10 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ACN9H16458; Thu, 10 Jun 2004 15:23:09 +0300 (EET DST) Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple elements From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <40C800D7.9010104@dynamicsoft.com> References: <40C800D7.9010104@dynamicsoft.com> Content-Type: text/plain; charset=iso-8859-13 Message-Id: <1086870176.2885.93.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 10 Jun 2004 15:22:56 +0300 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int2.ntc.nokia.com id i5ACN9H16458 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable On Thu, 2004-06-10 at 09:33, ext Jonathan Rosenberg wrote: > On the list, we had made some progress in coming up with an algorithm=20 > for executing the insertion request as a series of individual=20 > insertions. THe key trick was to make sure the entire operation was=20 > idempotent. >=20 > I did some further work during the interim, and found some additional=20 > problem cases in the algorithm, notably when you have a mix of ways of=20 > selecting an element. I presented this problem case. Lets say you start= =20 > with this document: >=20 > > > > >=20 >=20 > and then you do this: >=20 > PUT http://server/xcap-root/auid/users/joe/foo/bar[@id=3D=B41=A1]|foo/b= ar[3] >=20 > test > Uh oh >=20 > If you execute each of the two components in order, you get the=20 > following document: >=20 > > test > > Uh oh > >=20 >=20 > If you then do the GET back to the same URI: >=20 > GET http://server/xcap-root/auid/users/joe/foo/bar[@id=3D=B41=A1]|foo/b= ar[3] >=20 > It returns an error, since foo/bar[@id=3D"1"] now selects multiple=20 > elements. Thus, its not idempotent. >=20 > As such, I proposed two algorithms for the server side algorithm: >=20 > (1) basically, the server needs to look at the request, and prove=20 > idempotency before executing. It will need to check for all of these=20 > conditions that could cause the request to not be idempotent. >=20 > (2) the server keeps a copy of the document before the operation. It=20 > then tries the PUT. Once done, it pretends that the client did a GET=20 > back to the same URI, and it sees what comes back. If its the same as=20 > was in the body of the PUT, the operation was idempotent, and the PUT i= s=20 > accepted. If not, the server goes back to the document before the=20 > operation was done, and rejects the PUT request. This can be summarized= =20 > as "try it and see if it works". >=20 model (2) is almost what i have implemented for the following reason: first you have a document like and then a client might try to e.g. add foo/bar[@id=3D"5"] with content . First, as we don't find any node with the request, it is an appending request and without any error-checking you may end up with an end document like Clearly this is an error in the client and IMO the server has to detect this. The easy way that I chose to check this error-condition is that I check that the last XPATH location step will return the correct node. So my point is that not only the multi-inserts need this checking.=20 Jonathan, I have still this question in another thread, where idempotency is easily broken during replace (or modify) with single nodes too. Btw. could someone explain how DELETE can be idempotent (rfc2616) ? > Neither seemed particularly compelling, and there was a push from=20 > several participants, including myself, to just drop this functionality= =20 > in this version of the spec. This ties back into the discussion around=20 > issue 2 on positional insertions. >=20 > We discussed the impact on application usages. Hisham identified a=20 > problem in CPCP, where you want to add a user to the ACL and PCL at the= =20 > same time. It was suggested to make a schema change, so that the URI=20 > only appears once. The other idea was that, if you were concerned about= =20 > the latency of doing multiple operations, you could instead pipeline th= e=20 > HTTP PUT operations. So long as you don't need the etag from the=20 > previous operation, this would work. Its bandwidth overhead is almost=20 > the same as multiple insertions that we've been proposing, and the=20 > latency is just about the same thing too. >=20 I'd rather say that pipelining could work in some cases, but it is NOT a solution for doing atomic conditional multi-insertions/deletions which I still would like to see in XCAP.=20 > I suggested that I could include some guidelines on schema design to=20 > avoid the need for mutliple insertions. There seemed to be support for=20 > this position. The guidelines I will include are basically this: >=20 > (1) if you think you need multiple insertions because you think a commo= n=20 > operation will require making two separate changes to the document, try= =20 > "inverting" the schema so that this doesnt happen. For example, if you = have: >=20 > > > > > > > > >=20 > and adding requires it to go in and , try doing=20 > the schema like this: >=20 > > > > > > > > > > >=20 > (2) if you think you need multiple inserts because you want to add=20 > multiple entries to a list in one operation, then design the schema to=20 > facilitate pipelined PUT. Specifically, make sure that each entry in th= e=20 > list has a unique ID as an attribute, such that no other client is goin= g=20 > to choose the same id. Secondly, make sure your schema is such that the= =20 > path from the document root to this list is "unique". That means that=20 > its not possible to change the document such that this path expression=20 > remains valid, but points to a different list. This is typically done b= y=20 > making each element in the path mandatory to appear in the document, or= =20 > if its not mandatory, is identified by a unique attribute that would no= t=20 > be re-assigned. >=20 > Any objections? >=20 > Thanks, > Jonathan R. >=20 When I implemented XCAP resource-lists, I have used entry-nodes to represent other users with some additional information and then I have added corresponding entry-ref's to subcribeable lists e.g. "friends", "home", etc... So, it happens easily that if you e.g. remove a user you have to do multiple deletes or if you change user-names (which I used to use as keys) you have to change several entry-ref's. From the clients perspective, it is far easier (and cleaner) if I can do these changes with atomic conditional requests rather than doing either safe multiple single requests in sequence or IMO ugly blind pipelined requests. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 10:25:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10522 for ; Thu, 10 Jun 2004 10:25:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYQUf-0007Nb-9n for simple-archive@ietf.org; Thu, 10 Jun 2004 10:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYQTe-0006s6-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 10:24:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYQRn-0005Wj-00; Thu, 10 Jun 2004 10:22:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYQAA-0004fr-2L; Thu, 10 Jun 2004 10:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYOyU-0004vQ-My for simple@megatron.ietf.org; Thu, 10 Jun 2004 08:48: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 IAA29733 for ; Thu, 10 Jun 2004 08:48:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYOyT-0001ep-Tk for simple@ietf.org; Thu, 10 Jun 2004 08:48:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYOxZ-0001AW-00 for simple@ietf.org; Thu, 10 Jun 2004 08:47:09 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BYOwL-0000JW-00 for simple@ietf.org; Thu, 10 Jun 2004 08:45:54 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ACjox01679; Thu, 10 Jun 2004 15:45:50 +0300 (EET DST) X-Scanned: Thu, 10 Jun 2004 15:45:45 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5ACjj8G007856; Thu, 10 Jun 2004 15:45:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Nn5nLL; Thu, 10 Jun 2004 15:45:44 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ACjbH25911; Thu, 10 Jun 2004 15:45:37 +0300 (EET DST) Subject: RE: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions From: Jari Urpalainen To: "ext hisham.khartabil@nokia.com" In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C38@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797C38@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1086871523.7949.20.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 10 Jun 2004 15:45:24 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-06-10 at 11:43, ext hisham.khartabil@nokia.com wrote: > Jonathan, > > Thanks for the analysis. > > Reading your analysis actually brings me to the opposite conclusion to the one you made. That is, we need positional insertions. There are so many rules, restriction, and guide lines that need to be educated to current and future designers of XCAP friendly schemas. Wouldn't it be a much better investment if we allow positional insertions now and avoid schema misdesign? > > You haven't explicitly listed the issues with positional insertions, but instead you listed the problems that it solves. Can you please educate the rest of us what the real problems are with positional insertions? > > Thanks, > Hisham I agree totally with Hisham here. Probably the only technical (?) argument has been that XCAP is getting too complex. When I implemented these positional inserts I did not find any peculiar difficulties in the implementation. I find it really weird that xml Schemas has to be defined so that XCAP has no difficulty when doing updates. I'll agree that it's not bad if the situation is such, but I would not like to put that as a requirement while we'll have a simple solution at hand, IMHO. > > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org]On Behalf > > Of ext Jonathan Rosenberg > > Sent: 10.June.2004 08:54 > > To: Simple WG > > Subject: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions > > > > > > The issue of positional insertions was discussed during the interim. > > There was a lot of disagreement on it. There were concerns that it > > raised the bar too high for implementation complexity. This was tied > > back into a more general question about our goal here. Is our goal to > > (1) create a general purpose XML database management > > protocol, or (2) to > > create a simple tool for managing the set of documents > > important to the > > SIMPLE group. If its (1), then positional insertions make sense, but > > this is going to be a much larger problem and work item than SIMPLE > > can/should tackle. There is a lot of work already on XML database > > protocols that we will have to look at. > > e.g. XUpdate will do these positional insertions but with different semantics. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 11:42:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14001 for ; Thu, 10 Jun 2004 11:42:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYRh2-0003Mf-Kj for simple-archive@ietf.org; Thu, 10 Jun 2004 11:42:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYRg5-0002ua-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 11:41:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYRfC-000211-00; Thu, 10 Jun 2004 11:40:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYRZb-0003Ag-Nl; Thu, 10 Jun 2004 11:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYPCW-0008Ml-B0 for simple@megatron.ietf.org; Thu, 10 Jun 2004 09:02: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 JAA00977 for ; Thu, 10 Jun 2004 09:02:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYPCV-0001LG-LZ for simple@ietf.org; Thu, 10 Jun 2004 09:02:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYPBT-0000nW-00 for simple@ietf.org; Thu, 10 Jun 2004 09:01:32 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BYPAH-0000BV-00 for simple@ietf.org; Thu, 10 Jun 2004 09:00:17 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5AD0Ex21254; Thu, 10 Jun 2004 16:00:14 +0300 (EET DST) X-Scanned: Thu, 10 Jun 2004 16:00:06 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5AD06Ok023109; Thu, 10 Jun 2004 16:00:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00vRyO23; Thu, 10 Jun 2004 16:00:03 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5AD03H09555; Thu, 10 Jun 2004 16:00:03 +0300 (EET DST) Subject: Re: [Simple] XCAP Issue 4 Interim Summary: document to element separator From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <40C7FC2A.5080405@dynamicsoft.com> References: <40C7FC2A.5080405@dynamicsoft.com> Content-Type: text/plain Message-Id: <1086872390.7949.36.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 10 Jun 2004 15:59:50 +0300 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-06-10 at 09:14, ext Jonathan Rosenberg wrote: > This is the micro-issue that won't die. > > I had proposed the single quote as another choice. However, there was > concern that implementors would get this wrong, given the different > types of single quotes. It was pointed out that the separator doesnt > have to be a single character. So, "~~" was proposed (two tildes). This > seemed fine, and there was consensus to use that as the separator. > > Thanks, > Jonathan R. As Joel already noted that ~ is allowed in some ;) operating systems as a valid directory this applies to double tildes (file/directory) too. Of course the probability of having this sort of an error is rare it may happen. If this is still introduced the situation should at least be warned in the draft. BR, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 10 11:50:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14572 for ; Thu, 10 Jun 2004 11:50:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYRpJ-0007Mv-7Y for simple-archive@ietf.org; Thu, 10 Jun 2004 11:50:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYRoH-0006qb-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 11:49:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYRnQ-0006J5-00; Thu, 10 Jun 2004 11:48:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYRZd-0003CB-Sm; Thu, 10 Jun 2004 11:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYPSA-0005hP-Ul for simple@megatron.ietf.org; Thu, 10 Jun 2004 09:18: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 JAA02179 for ; Thu, 10 Jun 2004 09:18:45 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYPSA-0000oP-6M for simple@ietf.org; Thu, 10 Jun 2004 09:18:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYPNn-0007Du-00 for simple@ietf.org; Thu, 10 Jun 2004 09:14:16 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BYPLx-0006VY-00 for simple@ietf.org; Thu, 10 Jun 2004 09:12:21 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ADCBH19099; Thu, 10 Jun 2004 16:12:11 +0300 (EET DST) X-Scanned: Thu, 10 Jun 2004 16:11:43 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5ADBhvH006103; Thu, 10 Jun 2004 16:11:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Bm3xv1; Thu, 10 Jun 2004 16:11:41 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ADBaH18366; Thu, 10 Jun 2004 16:11:36 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Jun 2004 16:11:35 +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] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops Date: Thu, 10 Jun 2004 16:11:35 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C48@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops Thread-Index: AcROvezM9Ckhf7OMQT2MrU2V6ZOi9AALULLg To: , X-OriginalArrivalTime: 10 Jun 2004 13:11:35.0397 (UTC) FILETIME=[74EA3150:01C44EEC] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 10.June.2004 10:12 > To: Simple WG > Subject: [Simple] XCAP Issue 7 Interim Summary: uniqueness in > intermediatehops >=20 >=20 > This is an issue raised by Joel and discussed on the list.=20 > The problem=20 > was whether or not we would require the URI to select a=20 > unique element=20 > at each hop of its evaluation, or just make sure the final result of=20 > selection was unique. >=20 > If you are implementing XCAP without an XPATH library, this=20 > is a really=20 > nice feature to have. There is code and computational=20 > complexity if its=20 > not there. If you have an XPATH library, its a constraint=20 > that you need=20 > to explicitly verify outside of the xpath library, since XPATH does=20 > allow non-uniqueness at each hop. >=20 > There were continuing objections to the complexity introduced if each=20 > hop is not unique. As such, there was consensus on the uniqueness=20 > requirement. >=20 > However, Henning had a proposal to take this a step further. His=20 > proposal was that we could constrain XCAP so that at each=20 > step, you were=20 > selecting an element based on a unique index that was declared by the=20 > application usage to be unique. This way, you couldn't even=20 > ever have an=20 > expression which selected multiple things at each step. Here's an=20 > example to explain. Lets say we've got a schema that has a parent=20 > element called , and can have one or more children, each=20 > named . So, the following is a valid document: >=20 > > > >=20 > And thus, the expression "foo/bar" selects the element,=20 > and also=20 > gives you a single element at each step. Thus, it would be valid.=20 > However, in Hennings proposal, this expression would be=20 > illegal, since=20 > it might be the case that is not unique, and thus it=20 > could be the=20 > case that tbe expression "foo/bar" does not resolve to=20 > something unique.=20 > In such a case, the schema would have to mandate that each=20 > bar element=20 > have an attribute called "id" (for example), and that the application=20 > usage would mandate that this attribute be unique amongst all=20 > siblings.=20 > If you do that, then you can be guaranteed that the expression: >=20 > foo/bar[@id=3D"223"] >=20 > is unique. It may not point to anything, but if it does, it points to=20 > only one element. >=20 > Henning, if I have mis-interpreted your proposal, let me know. >=20 > This proposal was further refined. The idea was that an=20 > element needs to=20 > have a unique index only if it can appear more than once in the=20 > document. If it can appear only once, you don't need to=20 > define a unique=20 > attribute for it. >=20 > Upon further consideration, I concluded that the refined proposal was=20 > not a good idea. The objective of what Henning was proposing=20 > is that a=20 > server could look at the URI, and without needing to know the=20 > schema or=20 > even the instance document, determine whether the URI resolved to=20 > something unique. Of course, it could still resolve to nothing if any=20 > one of the indices didn't exist in the instance document. With the=20 > refined proposal, the server would need to know the schema to=20 > determine=20 > whether the URI was unique. No it doesn't. The server can still do the dynamic checking of the = instance document. Having refined proposal will aid in eliminating the = possibility of failure. eg: if we have then /foo/bar/baz expression is not unique at every step and therefore I = can never ever modify . If we define that "an element needs to have a unique index only if it = can appear more than once in the document. If it can appear only once, = you don't need to define a unique attribute for it", then the server can = still do the dynamic checking (if it does not trust the client) and it = enables the client to modify some parts of the instance document that = are otherwise unmodifiable. Regards, Hisham > That adds a lot of complexity;=20 > you'd need to=20 > plug some kind of meta-data about the schema into the xcap=20 > server, so it=20 > could figure out which elements were unique in the document,=20 > and which=20 > weren't. Thus, it would add more complexity than it would remove. >=20 > Indeed, for Henning's proposal to work, you'd need every=20 > schema to have=20 > the same attribute name as a unique index. For example, "id".=20 > We'd have=20 > to mandate that every document managed by XCAP, for each=20 > element in that=20 > document, have an attribute called "id" that's present in the=20 > doc, so we=20 > can use it as an index and guarantee its always there. >=20 > That eliminates the possibility of xcap managing existing=20 > documents (for=20 > example, PIDF). I think that is a costly result. Furthermore,=20 > you STILL=20 > need to parse through the document to determine if the URI points to=20 > something or nothing. Once you've committed to doing that, the=20 > additional cost of doing a dynamic check for unqiueness seems=20 > trivial to me. >=20 > Thus, I'd propose that we stick with our original conclusion,=20 > which is=20 > to mandate that the XCAP expression evaluate to a unique=20 > element at each=20 > step. This constraint would be checked by the server=20 > dynamically based=20 > on the instance document. >=20 > Objections? >=20 > -Jonathan R. > --=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-bounces@ietf.org Thu Jun 10 12:25:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16880 for ; Thu, 10 Jun 2004 12:25:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYSMn-0001Bu-B4 for simple-archive@ietf.org; Thu, 10 Jun 2004 12:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYSLl-0000iQ-00 for simple-archive@ietf.org; Thu, 10 Jun 2004 12:24:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYSKn-0007ah-00; Thu, 10 Jun 2004 12:23:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYRuh-0008Fw-Tu; Thu, 10 Jun 2004 11:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY7YL-0002WJ-J9 for simple@megatron.ietf.org; Wed, 09 Jun 2004 14:11: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 OAA06015 for ; Wed, 9 Jun 2004 14:11:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY7YK-0006lq-7H for simple@ietf.org; Wed, 09 Jun 2004 14:11:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY7Wb-0005qb-00 for simple@ietf.org; Wed, 09 Jun 2004 14:10:19 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BY7UH-0003IG-00 for simple@ietf.org; Wed, 09 Jun 2004 14:07:45 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i59I7ARn023867; Wed, 9 Jun 2004 13:07:11 -0500 (CDT) Message-ID: <40C751CD.10604@alcatel.com> Date: Wed, 09 Jun 2004 13:07:09 -0500 From: Alex Audu 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: hisham.khartabil@nokia.com Subject: Re: [Simple] Re: MSRP: Max message size indication References: <2038BCC78B1AD641891A0D1AE133DBB701797C14@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C14@esebe019.ntc.nokia.com> X-Mailman-Approved-At: Thu, 10 Jun 2004 10:33:30 -0400 Cc: drage@lucent.com, simple@ietf.org, christer.holmberg@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alex.audu@alcatel.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1054496402==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --===============1054496402== Content-Type: multipart/alternative; boundary="------------020001080304030803050300" This is a multi-part message in MIME format. --------------020001080304030803050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by auds953.usa.alcatel.com id i59I7ARn023867 Content-Transfer-Encoding: quoted-printable I think there is great value in end-point being able to signal the=20 maximum size of data it is willing /able to accept at a time. This information could be used by the=20 sender to, for example send a less memory intensive version of say an image, instead of a full=20 blown memory hungry version. This will allow the information to be communicated with a=20 decreased risk of truncation at first try. That makes for a more efficient communication (than=20 without this feature). I don't see the need to signal max-send size. So I vote yes/no Cheers, Alex. hisham.khartabil@nokia.com wrote: >Furthermore. If my terminal has 10Meg free memory and some logic decides= that my IM session application gets 10% of that (1 Meg), so I signal max= -receive-size of 1 Meg. > >In the mean time, I have downloaded a 9 Meg mpeg from some sight. My quo= ta for IMS session would now change to 100K. Do I resignal that max-recei= ve-size has changed? > >Also, after I have signalled that the max-receive-size is 1Meg, I receiv= e a 1 Meg message and I accept it (since it did not exceed the 1Meg max s= ize limit). Then I receive a second one of those 1 Meg messages, do I acc= ept? > >What does max-receive-size really mean? Max size of messages in total in= this session? Max size of 1 message? How can I ever possibly determine t= he maximum message size I can receive is? In any case, rejecting a messag= e because of size needs to be supported. > >Too many questions, too little time -> I vote no/no (not as a chair) > >/Hisham > > =20 > >>-----Original Message----- >>From: simple-bounces@ietf.org=20 >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Drage, Keith (Keith) >>Sent: 08.June.2004 16:51 >>To: Christer Holmberg (JO/LMF) >>Cc: simple@ietf.org >>Subject: RE: [Simple] Re: MSRP: Max message size indication >> >> >>Arguing that it is optional does not mean it should go into=20 >>an RFC with issues attached. We have to solve all the issues=20 >>even for optional capabilities, and even with restrictions,=20 >>to be be adopted, it must still be useful. >> >>Our concern on this is that while a message receiver may know=20 >>the maximum size messages it can buffer, any message sender=20 >>would require an interaction with the use of the application=20 >>to decide what that maximum might be. In most, if not all=20 >>message sessions, that sending size might not be known until=20 >>the time it is required to send a message, and the overflow=20 >>may possibly not be known until the sender has started=20 >>sending the message. >> >>Thus I see some need by the receiver of a message to abort a=20 >>message when the internal buffers get full. What happens then=20 >>- we still need to deal with this case even if a size is=20 >>negotiated. My assumption is that an application would do the=20 >>best to render what it has, accompanied by some meaningful=20 >>notation. Further recovery would then take place at the=20 >>application layer, e.g. a reply message saying "send your=20 >>message again without the picture because it was too big for=20 >>my receiver to handle".=20 >> >>Now give that we have to do that anyway, do we gain any=20 >>advantage in the few cases where the future message size is=20 >>known at session establishment time. >> >>regards >> >>Keith >> >> =20 >> >>>-----Original Message----- >>>From: Christer Holmberg (JO/LMF)=20 >>>[mailto:christer.holmberg@ericsson.com] >>>Sent: 07 June 2004 18:23 >>>To: 'Paul Kyzivat'; Ben Campbell >>>Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org >>>Subject: RE: [Simple] Re: MSRP: Max message size indication >>> >>> >>> >>>Hi, >>> >>>I disagree, and my answer is yes/yes. >>> >>> =20 >>> >>>>I'm inclined to agree with you (no/no). For many nodes this=20 >>>> =20 >>>> >>>is simply=20 >>> =20 >>> >>>>not a number that is easily decided. If anything, I imagine=20 >>>>it would be best to negotiate this. But that requires the=20 >>>> =20 >>>> >>>sender to pick=20 >>> =20 >>> >>>>a maximum send value, even though the sender probably has no=20 >>>> =20 >>>> >>>particular limit.=20 >>> =20 >>> >>>>This just seems like a rat hole best avoided for now. >>>> =20 >>>> >>>The support and use of the attribute/parameter would be=20 >>>OPTIONAL, so if a node doesn't support the=20 >>>attribute/parameter (it is not able to calculate a value, it=20 >>>can't be configured, or the node simply thinks that size=20 >>>doesn't matter) everything will still work, as today, and it=20 >>>will then be "local policy" what to do if the messages can't=20 >>>be handled. >>> >>>Of course, a node can send a 4xx response if the message it=20 >>>receives is too big, but as I said before, there may be=20 >>>scenarios where the size information is used to make=20 >>>decissions already at the session setup phase. >>> >>>As Andrew said, this feature is especially useful for mobile=20 >>>devices, or other nodes with limited memory. >>> >>>And, since there is a requirement at least for the receiving=20 >>>part, I assume it at some stage has been realized that the=20 >>>information could be useful. >>> >>>Regards, >>> >>>Christer Holmberg >>>Ericsson Finland >>> >>> >>> >>> >>> >>> =20 >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: 7. kes=E4kuuta 2004 19:55 >>>>To: Ben Campbell >>>>Cc: Chris Boulton; hisham.khartabil@nokia.com;=20 >>>>simple@ietf.org; Christer >>>>Holmberg (JO/LMF) >>>>Subject: Re: [Simple] Re: MSRP: Max message size indication >>>> >>>> >>>>Ben, >>>> >>>> >>>> Paul >>>> >>>>Ben Campbell wrote: >>>> =20 >>>> >>>>>I'd like to try and get some closure on this: >>>>> >>>>>Please answer yes or no to the following: >>>>> >>>>>1) Should we add the optional signaling of the maximum=20 >>>>> =20 >>>>> >>>>content size you=20 >>>> =20 >>>> >>>>>are willing to _receive_ into the SDP exchange. >>>>> >>>>>2) Should we add the optional signaling of the maximum=20 >>>>> =20 >>>>> >>>>content size you=20 >>>> =20 >>>> >>>>>are planning to _send_ into the SDP exchange. >>>>> >>>>>3) If either 1 or 2 is yes, do we send one value for the=20 >>>>> =20 >>>>> >>>>session, or one=20 >>>> =20 >>>> >>>>>value per each type for which we have indicated support. >>>>> >>>>>My personal opinions: >>>>> >>>>>No and No. In all honesty, I think this could be a useful=20 >>>>> =20 >>>>> >>>>feature, but I=20 >>>> =20 >>>> >>>>>don't think MSRP has to have it to function. I am voting=20 >>>>> =20 >>>>> >>>>no, not because=20 >>>> =20 >>>> >>>>>I disagree with the feature, but because I don't want to=20 >>>>> =20 >>>>> >>>>add additional=20 >>>> =20 >>>> >>>>>work to completing MSRP unless it is absolutely=20 >>>>> =20 >>>>> >>necessary. But if=20 >> =20 >> >>>>>consensus says we need it, I do not object on any=20 >>>>> =20 >>>>> >>technical basis. >> =20 >> >>>>> >>>>> >>>>>Chris Boulton wrote: >>>>> >>>>> =20 >>>>> >>>>>>I think this feature would certainly be useful for max=20 >>>>>> =20 >>>>>> >>>>receive (if it=20 >>>> =20 >>>> >>>>>>was type specific) BUT I am not convinced about send. >>>>>>=20 >>>>>>Chris. >>>>>>=20 >>>>>> >>>>>> -----Original Message----- From: Ben Campbell=20 >>>>>>[mailto:bcampbell@dynamicsoft.com] Sent: Tue=20 >>>>>> =20 >>>>>> >>>25/05/2004 18:27=20 >>> =20 >>> >>>>>> To: Christer Holmberg (JO/LMF) Cc:=20 >>>>>> =20 >>>>>> >>>>hisham.khartabil@nokia.com;=20 >>>> =20 >>>> >>>>>>simple@ietf.org Subject: Re: [Simple] Re: MSRP: Max=20 >>>>>> =20 >>>>>> >>>>message size=20 >>>> =20 >>>> >>>>>>indication >>>>>> =20 >>>>>> =20 >>>>>> >>>>>> Let me step up a level: >>>>>> =20 >>>>>> By the required vs useful discussion, I was=20 >>>>>> =20 >>>>>> >>referring to the=20 >> =20 >> >>>>>>feature of >>>>>> being able to signal size limitations itself, rather=20 >>>>>> =20 >>>>>> >>>than some=20 >>> =20 >>> >>>>>>aspect of >>>>>> the feature. >>>>>> =20 >>>>>> So, what do others about whether the feature of being=20 >>>>>> =20 >>>>>> >>>>able to signal >>>> =20 >>>> >>>>>> message size limits is required? >>>>>> =20 >>>>>> Christer Holmberg (JO/LMF) wrote: >>>>>> =20 >>>>>> > Hi, >>>>>> > >>>>>> > >>>>>> >>(Ignore my yet-another-empty reply. This time I=20 >>>>>> =20 >>>>>> >>>>blame the combined >>>> =20 >>>> >>>>>> >>ergonomics of Thunderbird and my laptop.) >>>>>> >> >>>>>> >>That brings up an interesting meta-question. What=20 >>>>>> =20 >>>>>> >>>is the bar >>> =20 >>> >>>>>> >>for putting new features into MSRP at this stage? Is=20 >>>>>> =20 >>>>>> >>>>"useful"=20 >>>> =20 >>>> >>>>>>enough? Or >>>>>> >>should we limit new features to things that we=20 >>>>>> =20 >>>>>> >>decide are=20 >> =20 >> >>>>>>"required." >>>>>> > >>>>>> > >>>>>> > Well, the max-receive is required, and I think=20 >>>>>> =20 >>>>>> >>it is very=20 >> =20 >> >>>>>>useful. As I wrote earlier, the question is if it should=20 >>>>>> =20 >>>>>> >>>>be possible=20 >>>> =20 >>>> >>>>>>to indicate separate values for different media types. >>>>>> > >>>>>> > The max-send is not required, but I still think it=20 >>>>>> =20 >>>>>> >>>>would be very=20 >>>> =20 >>>> >>>>>>useful. Earlier I gave some examples I think are very=20 >>>>>> =20 >>>>>> >>>>valid (nodes may=20 >>>> =20 >>>> >>>>>>try to reserve memory according to how much big messages=20 >>>>>> =20 >>>>>> >>>then can=20 >>> =20 >>> >>>>>>expect to receive, redirection/forking may be done=20 >>>>>> =20 >>>>>> >>based on the=20 >> =20 >> >>>>>>information etc etc etc). It wouldn't have any impacts on=20 >>>>>> =20 >>>>>> >>>>the protocol=20 >>>> =20 >>>> >>>>>>functionality itself, and there would be no interop=20 >>>>>> =20 >>>>>> >>>problems with=20 >>> =20 >>> >>>>>>nodes that don't understand the max-send=20 >>>>>> =20 >>>>>> >>>>attribute/parameter (or just=20 >>>> =20 >>>> >>>>>>don't care about it). >>>>>> > >>>>>> > Regards, >>>>>> > >>>>>> > Christer Holmberg >>>>>> > Ericsson Finland >>>>>> > >>>>>> > >>>>>> > >>>>>> >>hisham.khartabil@nokia.com wrote: >>>>>> >> >>>>>> >> >>>>>> >>>I think max-receive is useful, but not max-send. >>>>>> >>> >>>>>> >>>/Hisham >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>>>-----Original Message----- >>>>>> >>>>From: simple-bounces@ietf.org >>>>>> >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>>> >>>>Of ext Ben Campbell >>>>>> >>>>Sent: 25.May.2004 17:49 >>>>>> >>>>To: Christer Holmberg (JO/LMF) >>>>>> >>>>Cc: 'simple@ietf.org' >>>>>> >>>>Subject: [Simple] Re: MSRP: Max message size indication >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>(Oops, itchy trigger finger--ignore my last mail=20 >>>>>> =20 >>>>>> >>>>on the subject.) >>>> =20 >>>> >>>>>> >>>> >>>>>> >>>>I do not have strong feelings on this as a=20 >>>>>> =20 >>>>>> >>>>requirement. If we >>>> =20 >>>> >>>>>> >>>>do want to >>>>>> >>>>do it, the general approach seems good at the=20 >>>>>> =20 >>>>>> >>>first read,=20 >>> =20 >>> >>>>>>anyway. I >>>>>> >>>>don't think there is a need for the non-type=20 >>>>>> =20 >>>>>> >>>specific size >>> =20 >>> >>>>>> >> >>>>>> >>attribute. >>>>>> >> >>>>>> >>>>The only advantage would be to reduce size of=20 >>>>>> =20 >>>>>> >>the SDP. I >> =20 >> >>>>>> >>>>don't see that >>>>>> >>>>as a big requirement, since it normally only=20 >>>>>> =20 >>>>>> >>happens one >> =20 >> >>>>>> >> >>>>>> >>per session. >>>>>> >> >>>>>> >>>>Do others have thoughts on the matter? Do we need this >>>>>> >> >>>>>> >>feature at all? >>>>>> >> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>Christer Holmberg (JO/LMF) wrote: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>Hi, >>>>>> >>>>> >>>>>> >>>>>As agreed at the SIMPLE interim meeting MSRP=20 >>>>>> =20 >>>>>> >>>discussion I >>> =20 >>> >>>>>> >>>> >>>>>> >>>>am bringing to the list the issue about being able to >>>>>> >>>>indicate the max content size a node is able=20 >>>>>> =20 >>>>>> >>to receive. >> =20 >> >>>>>> >>>>Also, as input, in chapter 4 of >>>>>> =20 >>>>>> =20 >>>>>> >>>>>>>>draft-rosenberg-simple-messaging-requirements-01.txt there is >>>>>>>> =20 >>>>>>>> >>>>>> >>>>a requirement for such functionality: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>REQ-CONTENT-1: A UA MUST be able to indicate=20 >>>>>> =20 >>>>>> >>the maximum >> =20 >> >>>>>> >>>> >>>>>> >>>>message size it is willing to receive. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>I think it would be useful if clients could=20 >>>>>> =20 >>>>>> >>indicate the >> =20 >> >>>>>> >>>> >>>>>> >>>>maximum payload size he is able to receive, and=20 >>>>>> =20 >>>>>> >>>also send, >>> =20 >>> >>>>>> >>>>either per type or stream. Note that I am=20 >>>>>> =20 >>>>>> >>>talking about the >>> =20 >>> >>>>>> >>>>total message/content size, not the size of individual >>>>>> >>>>fragments (the spec does say that messages=20 >>>>>> =20 >>>>>> >>bigger than 2k >> =20 >> >>>>>> >>>>should be fragmented). >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>If the max size is dependent on the media=20 >>>>>> =20 >>>>>> >>type, max size >> =20 >> >>>>>> >>>> >>>>>> >>>>could be defined as a accept-type token paramter: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>example: >>>>>> >>>>> >>>>>> >>>>>accept-type: X;max-send=3D1000;max-receive=3D1000, >>>>>> >>>> >>>>>> >>>>Y;max-send=3D2000;max-receive=3D500 >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>And, if the message size it not type dependent,=20 >>>>>> =20 >>>>>> >>>>generic max >>>> =20 >>>> >>>>>> >>>> >>>>>> >>>>size attributes could be used. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>example: >>>>>> >>>>> >>>>>> >>>>>a=3Dmax-send: 1000 >>>>>> >>>>>a=3Dmax-receive:1000 >>>>>> >>>>> >>>>>> >>>>>Even if one is not going to send more than the=20 >>>>>> =20 >>>>>> >>>other party >>> =20 >>> >>>>>> >>>> >>>>>> >>>>indicates he is able to receive I still think it=20 >>>>>> =20 >>>>>> >>>>is important >>>> =20 >>>> >>>>>> >>>>that a node can indicate how much he is able=20 >>>>>> =20 >>>>>> >>to send. For >> =20 >> >>>>>> >>>>example, the remote node may reserve memory=20 >>>>>> =20 >>>>>> >>>>according to that >>>> =20 >>>> >>>>>> >>>>information, and/or intermediate proxies may do >>>>>> >>>>forking/routing based on the client capabilities. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>An MSRP "message size too big" error code=20 >>>>>> =20 >>>>>> >>could also be >> =20 >> >>>>>> >>>> >>>>>> >>>>useful, if a node for whatever reason is not able=20 >>>>>> =20 >>>>>> >>>>to accept a >>>> =20 >>>> >>>>>> >>>>SEND message. This may be due to that the=20 >>>>>> =20 >>>>>> >>remote node is >> =20 >> >>>>>> >>>>sending more data than was agreed in the=20 >>>>>> =20 >>>>>> >>>offer/answer, but >>> =20 >>> >>>>>> >>>>also due to that the receiving node for a short=20 >>>>>> =20 >>>>>> >>>>period isn't >>>> =20 >>>> >>>>>> >>>>able to receive the agreed data size (if the max=20 >>>>>> =20 >>>>>> >>>>size change >>>> =20 >>>> >>>>>> >>>>is permanent a new offer should of course be sent,=20 >>>>>> =20 >>>>>> >>>>instead of >>>> =20 >>>> >>>>>> >>>>sending an error reply to every SEND). At the=20 >>>>>> =20 >>>>>> >>>>interim meeting >>>> =20 >>>> >>>>>> >>>>is was desired to have a mechanism to "interrupt" the >>>>>> >>>>receival of a message, and this error code could=20 >>>>>> =20 >>>>>> >>>be used to >>> =20 >>> >>>>>> >>>>indicate that. The sender would then stop sending the >>>>>> >>>>message, and any possible yet unsent fragments. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>Regards, >>>>>> >>>>> >>>>>> >>>>>Christer Holmberg >>>>>> >>>>>Ericsson Finland >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>_______________________________________________ >>>>>> >>>>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 >>>>>> >>>>>> >>>>>> >>>>>>This message has been scanned for viruses by MailControl -=20 >>>>>>www.mailcontrol.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 >>>>> >>>>> =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 >> >> =20 >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > =20 > --------------020001080304030803050300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think there is great value in  end-point being able to signal the maximum size of data it is
willing /able to accept at a time. This information could be used by the sender to, for example
send a less memory intensive version of say an image, instead of a full blown memory hungry
version.  This will allow the information to be communicated with a decreased risk of truncation
at first try. That makes for a more efficient communication (than without this feature).

I don't see the need  to signal max-send size.   So I vote yes/no

Cheers,
Alex.


hisham.khartabil@nokia.com wrote:
Furthermore. If my terminal has 10Meg free memory and some logic decides that my IM session application gets 10% of that (1 Meg), so I signal max-receive-size of 1 Meg.

In the mean time, I have downloaded a 9 Meg mpeg from some sight. My quota for IMS session would now change to 100K. Do I resignal that max-receive-size has changed?

Also, after I have signalled that the max-receive-size is 1Meg, I receive a 1 Meg message and I accept it (since it did not exceed the 1Meg max size limit). Then I receive a second one of those 1 Meg messages, do I accept?

What does max-receive-size really mean? Max size of messages in total in this session? Max size of 1 message? How can I ever possibly determine the maximum message size I can receive is? In any case, rejecting a message because of size needs to be supported.

Too many questions, too little time -> I vote no/no (not as a chair)

/Hisham

  
-----Original Message-----
From: simple-bounces@ietf.org 
[mailto:simple-bounces@ietf.org]On Behalf
Of ext Drage, Keith (Keith)
Sent: 08.June.2004 16:51
To: Christer Holmberg (JO/LMF)
Cc: simple@ietf.org
Subject: RE: [Simple] Re: MSRP: Max message size indication


Arguing that it is optional does not mean it should go into 
an RFC with issues attached. We have to solve all the issues 
even for optional capabilities, and even with restrictions, 
to be be adopted, it must still be useful.

Our concern on this is that while a message receiver may know 
the maximum size messages it can buffer, any message sender 
would require an interaction with the use of the application 
to decide what that maximum might be. In most, if not all 
message sessions, that sending size might not be known until 
the time it is required to send a message, and the overflow 
may possibly not be known until the sender has started 
sending the message.

Thus I see some need by the receiver of a message to abort a 
message when the internal buffers get full. What happens then 
- we still need to deal with this case even if a size is 
negotiated. My assumption is that an application would do the 
best to render what it has, accompanied by some meaningful 
notation. Further recovery would then take place at the 
application layer, e.g. a reply message saying "send your 
message again without the picture because it was too big for 
my receiver to handle". 

Now give that we have to do that anyway, do we gain any 
advantage in the few cases where the future message size is 
known at session establishment time.

regards

Keith

    
-----Original Message-----
From: Christer Holmberg (JO/LMF) 
[mailto:christer.holmberg@ericsson.com]
Sent: 07 June 2004 18:23
To: 'Paul Kyzivat'; Ben Campbell
Cc: hisham.khartabil@nokia.com; Chris Boulton; simple@ietf.org
Subject: RE: [Simple] Re: MSRP: Max message size indication



Hi,

I disagree, and my answer is yes/yes.

      
I'm inclined to agree with you (no/no). For many nodes this 
        
is simply 
      
not a number that is easily decided. If anything, I imagine 
it would be  best to negotiate this. But that requires the 
        
sender to pick 
      
a maximum send value, even though the sender probably has no 
        
particular limit. 
      
This just seems like a rat hole best avoided for now.
        
The support and use of the attribute/parameter would be 
OPTIONAL, so if a node doesn't support the 
attribute/parameter (it is not able to calculate a value, it 
can't be configured, or the node simply thinks that size 
doesn't matter) everything will still work, as today, and it 
will then be "local policy" what to do if the messages can't 
be handled.

Of course, a node can send a 4xx response if the message it 
receives is too big, but as I said before, there may be 
scenarios where the size information is used to make 
decissions already at the session setup phase.

As Andrew said, this feature is especially useful for mobile 
devices, or other nodes with limited memory.

And, since there is a requirement at least for the receiving 
part, I assume it at some stage has been realized that the 
information could be useful.

Regards,

Christer Holmberg
Ericsson Finland





      
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: 7. kesäkuuta 2004 19:55
To: Ben Campbell
Cc: Chris Boulton; hisham.khartabil@nokia.com; 
simple@ietf.org; Christer
Holmberg (JO/LMF)
Subject: Re: [Simple] Re: MSRP: Max message size indication


Ben,


	Paul

Ben Campbell wrote:
        
I'd like to try and get some closure on this:

Please answer yes or no to the following:

1) Should we add the optional signaling of the maximum 
          
content size you 
        
are willing to _receive_ into the SDP exchange.

2) Should we add the optional signaling of the maximum 
          
content size you 
        
are planning to _send_ into the SDP exchange.

3) If either 1 or 2 is yes, do we send one value for the 
          
session, or one 
        
value per each type for which we have indicated support.

My personal opinions:

No and No. In all honesty, I think this could be a useful 
          
feature, but I 
        
don't think MSRP has to have it to function. I am voting 
          
no, not because 
        
I disagree with the feature, but because I don't want to 
          
add additional 
        
work to completing MSRP unless it is absolutely 
          
necessary. But if 
    
consensus says we need it, I do not object on any 
          
technical basis.
    


Chris Boulton wrote:

          
I think this feature would certainly be useful for max 
            
receive (if it 
        
was type specific) BUT I am not convinced about send.
 
Chris.
 

    -----Original Message-----     From: Ben Campbell 
[mailto:bcampbell@dynamicsoft.com]     Sent: Tue 
            
25/05/2004 18:27 
      
    To: Christer Holmberg (JO/LMF)     Cc: 
            
hisham.khartabil@nokia.com; 
        
simple@ietf.org     Subject: Re: [Simple] Re: MSRP: Max 
            
message size 
        
indication
    
    

    Let me step up a level:
    
    By the required vs useful discussion, I was 
            
referring to the 
    
feature of
    being able to signal size limitations itself, rather 
            
than some 
      
aspect of
    the feature.
    
    So, what do others about whether the feature of being 
            
able to signal
        
    message size limits is required?
    
    Christer Holmberg (JO/LMF) wrote:
    
    > Hi,
    >
    >
    >>(Ignore my yet-another-empty reply. This time I 
            
blame the combined
        
    >>ergonomics of Thunderbird and my laptop.)
    >>
    >>That brings up an interesting meta-question. What 
            
is the bar
      
    >>for putting new features into MSRP at this stage? Is 
            
"useful" 
        
enough? Or
    >>should we limit new features to things that we 
            
decide are 
    
"required."
    >
    >
    > Well, the max-receive is required, and I think 
            
it is very 
    
useful. As I wrote earlier, the question is if it should 
            
be possible 
        
to indicate separate values for different media types.
    >
    > The max-send is not required, but I still think it 
            
would be very 
        
useful. Earlier I gave some examples I think are very 
            
valid (nodes may 
        
try to reserve memory according to how much big messages 
            
then can 
      
expect to receive, redirection/forking may be done 
            
based on the 
    
information etc etc etc). It wouldn't have any impacts on 
            
the protocol 
        
functionality itself, and there would be no interop 
            
problems with 
      
nodes that don't understand the max-send 
            
attribute/parameter (or just 
        
don't care about it).
    >
    > Regards,
    >
    > Christer Holmberg
    > Ericsson Finland
    >
    >
    >
    >>hisham.khartabil@nokia.com wrote:
    >>
    >>
    >>>I think max-receive is useful, but not max-send.
    >>>
    >>>/Hisham
    >>>
    >>>
    >>>
    >>>>-----Original Message-----
    >>>>From: simple-bounces@ietf.org
    >>>>[mailto:simple-bounces@ietf.org]On Behalf
    >>>>Of ext Ben Campbell
    >>>>Sent: 25.May.2004 17:49
    >>>>To: Christer Holmberg (JO/LMF)
    >>>>Cc: 'simple@ietf.org'
    >>>>Subject: [Simple] Re: MSRP: Max message size indication
    >>>>
    >>>>
    >>>>(Oops, itchy trigger finger--ignore my last mail 
            
on the subject.)
        
    >>>>
    >>>>I do not have strong feelings on this as a 
            
requirement. If we
        
    >>>>do want to
    >>>>do it, the general approach seems good at the 
            
first read, 
      
anyway. I
    >>>>don't think there is a need for the non-type 
            
specific size
      
    >>
    >>attribute.
    >>
    >>>>The only advantage would be to reduce size of 
            
the SDP. I
    
    >>>>don't see that
    >>>>as a big requirement, since it normally only 
            
happens one
    
    >>
    >>per session.
    >>
    >>>>Do others have thoughts on the matter? Do we need this
    >>
    >>feature at all?
    >>
    >>>>
    >>>>
    >>>>Christer Holmberg (JO/LMF) wrote:
    >>>>
    >>>>
    >>>>
    >>>>>Hi,
    >>>>>
    >>>>>As agreed at the SIMPLE interim meeting MSRP 
            
discussion I
      
    >>>>
    >>>>am bringing to the list the issue about being able to
    >>>>indicate the max content size a node is able 
            
to receive.
    
    >>>>Also, as input, in chapter 4 of
    
            
draft-rosenberg-simple-messaging-requirements-01.txt there is
                
    >>>>a requirement for such functionality:
    >>>>
    >>>>
    >>>>>REQ-CONTENT-1: A UA MUST be able to indicate 
            
the maximum
    
    >>>>
    >>>>message size it is willing to receive.
    >>>>
    >>>>
    >>>>>I think it would be useful if clients could 
            
indicate the
    
    >>>>
    >>>>maximum payload size he is able to receive, and 
            
also send,
      
    >>>>either per type or stream. Note that I am 
            
talking about the
      
    >>>>total message/content size, not the size of individual
    >>>>fragments (the spec does say that messages 
            
bigger than 2k
    
    >>>>should be fragmented).
    >>>>
    >>>>
    >>>>>If the max size is dependent on the media 
            
type, max size
    
    >>>>
    >>>>could be defined as a accept-type token paramter:
    >>>>
    >>>>
    >>>>>example:
    >>>>>
    >>>>>accept-type: X;max-send=1000;max-receive=1000,
    >>>>
    >>>>Y;max-send=2000;max-receive=500
    >>>>
    >>>>
    >>>>>And, if the message size it not type dependent, 
            
generic max
        
    >>>>
    >>>>size attributes could be used.
    >>>>
    >>>>
    >>>>>example:
    >>>>>
    >>>>>a=max-send: 1000
    >>>>>a=max-receive:1000
    >>>>>
    >>>>>Even if one is not going to send more than the 
            
other party
      
    >>>>
    >>>>indicates he is able to receive I still think it 
            
is important
        
    >>>>that a node can indicate how much he is able 
            
to send. For
    
    >>>>example, the remote node may reserve memory 
            
according to that
        
    >>>>information, and/or intermediate proxies may do
    >>>>forking/routing based on the client capabilities.
    >>>>
    >>>>
    >>>>>An MSRP "message size too big" error code 
            
could also be
    
    >>>>
    >>>>useful, if a node for whatever reason is not able 
            
to accept a
        
    >>>>SEND message. This may be due to that the 
            
remote node is
    
    >>>>sending more data than was agreed in the 
            
offer/answer, but
      
    >>>>also due to that the receiving node for a short 
            
period isn't
        
    >>>>able to receive the agreed data size (if the max 
            
size change
        
    >>>>is permanent a new offer should of course be sent, 
            
instead of
        
    >>>>sending an error reply to every SEND). At the 
            
interim meeting
        
    >>>>is was desired to have a mechanism to "interrupt" the
    >>>>receival of a message, and this error code could 
            
be used to
      
    >>>>indicate that. The sender would then stop sending the
    >>>>message, and any possible yet unsent fragments.
    >>>>
    >>>>
    >>>>>Regards,
    >>>>>
    >>>>>Christer Holmberg
    >>>>>Ericsson Finland
    >>>>
    >>>>
    >>>>_______________________________________________
    >>>>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
    



This message has been scanned for viruses by MailControl - 
www.mailcontrol.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

          
_______________________________________________
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
--------------020001080304030803050300-- --===============1054496402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1054496402==-- From simple-bounces@ietf.org Fri Jun 11 08:38:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18856 for ; Fri, 11 Jun 2004 08:38:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYlJA-0000OB-W7 for simple-archive@ietf.org; Fri, 11 Jun 2004 08:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYlEM-0006cV-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 08:33:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYlD0-00060U-02; Fri, 11 Jun 2004 08:32:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYl9x-0004JV-TM; Fri, 11 Jun 2004 08:29:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTA-0000oe-UY; Fri, 11 Jun 2004 07:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYU3L-0001Xo-Bg for simple@megatron.ietf.org; Thu, 10 Jun 2004 14:13: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 OAA21986 for ; Thu, 10 Jun 2004 14:13:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYU3D-0003Y1-B0 for simple@ietf.org; Thu, 10 Jun 2004 14:13:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYU2O-00036x-00 for simple@ietf.org; Thu, 10 Jun 2004 14:12:28 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BYU1M-0002Iv-00 for simple@ietf.org; Thu, 10 Jun 2004 14:11:24 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7054545 for simple@ietf.org; Thu, 10 Jun 2004 14:11:05 -0400 Message-Id: <5.1.0.14.0.20040610140711.024347d0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jun 2004 14:10:45 -0400 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple elements In-Reply-To: <40C800D7.9010104@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think leaving out multiple inserts, and telling people how to cope with the absence is MUCH better than the complications we are going to get by trying to include multiple inserts. Thank you, Joel At 02:33 AM 6/10/2004 -0400, Jonathan Rosenberg wrote: >[problem statement with non idempotent multiple insert] > >[Proposals for enforcing idempotentence] >.... >[Suggestion that we leave out multiple inserts.] >I suggested that I could include some guidelines on schema design to avoid >the need for mutliple insertions. There seemed to be support for this >position. The guidelines I will include are basically this: > >[Guidelines for avoiding the need for multiple inserts.] > >Any objections? > >Thanks, >Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 11 09:37:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26061 for ; Fri, 11 Jun 2004 09:37:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYmDZ-0007iS-QC for simple-archive@ietf.org; Fri, 11 Jun 2004 09:37:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYm4g-0005Q0-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 09:28:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYlux-0002lk-01; Fri, 11 Jun 2004 09:17:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUa-0001AA-Tw; Fri, 11 Jun 2004 07:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYZYI-0004CQ-Uo for simple@megatron.ietf.org; Thu, 10 Jun 2004 20:05: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 UAA07482 for ; Thu, 10 Jun 2004 20:05:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYZYH-0005Nl-AI for simple@ietf.org; Thu, 10 Jun 2004 20:05:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYZX9-0004u6-00 for simple@ietf.org; Thu, 10 Jun 2004 20:04:36 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BYZW8-00040O-00 for simple@ietf.org; Thu, 10 Jun 2004 20:03:32 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5B02w622713 for ; Thu, 10 Jun 2004 19:02:59 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 11 Jun 2004 01:02:57 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C41511B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg , Simple WG Subject: RE: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions Date: Fri, 11 Jun 2004 01:02:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I concur with the conclusion. However, we should also leave the issue of future extensions on the table until we get to that point. At that point we may still decide it is a level of complexity where we do not want XCAP to go (for the reason that there are other valid XML database alternatives for people that need this complexity). regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 10 June 2004 06:54 > To: Simple WG > Subject: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions > > > > As such, my proposal is to drop positional insertions for this first > version, and include them in an extension to be developed downstream. > > 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-bounces@ietf.org Fri Jun 11 09:43:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27187 for ; Fri, 11 Jun 2004 09:43:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYmJI-00010d-PW for simple-archive@ietf.org; Fri, 11 Jun 2004 09:43:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYmC1-00074j-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 09:35:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYm2g-0004ib-00; Fri, 11 Jun 2004 09:25:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYm2h-0000cK-GS; Fri, 11 Jun 2004 09:25:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUh-0001Bk-Fc; Fri, 11 Jun 2004 07:46:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYgc2-0006eG-Nn for simple@megatron.ietf.org; Fri, 11 Jun 2004 03:38: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 DAA04285 for ; Fri, 11 Jun 2004 03:37:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYgbl-0006z3-5e for simple@ietf.org; Fri, 11 Jun 2004 03:37:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYgar-0006Ze-00 for simple@ietf.org; Fri, 11 Jun 2004 03:36:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BYgaW-0006A1-00 for simple@ietf.org; Fri, 11 Jun 2004 03:36:32 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5B7aMd23923; Fri, 11 Jun 2004 10:36:22 +0300 (EET DST) X-Scanned: Fri, 11 Jun 2004 10:36:16 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5B7aGk9022225; Fri, 11 Jun 2004 10:36:16 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Pfmumq; Fri, 11 Jun 2004 10:36:14 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5B7aDH25824; Fri, 11 Jun 2004 10:36:13 +0300 (EET DST) Received: from [172.21.81.43] ([172.21.81.43]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Jun 2004 10:35:59 +0300 Message-ID: <40C960DF.8070702@nokia.com> Date: Fri, 11 Jun 2004 10:35:59 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> In-Reply-To: <40C78CE9.6010507@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2004 07:35:59.0967 (UTC) FILETIME=[BDAD26F0:01C44F86] Content-Transfer-Encoding: 7bit Cc: Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: ...snip... > That is, I think we shouldn't use the presence or absence of the contact > URI in the tuple to mean that the tuple is modeling something > fundamentally different. Rather, the absence of the contact URI means > that the presentity is unable or unwilling to disclose the URI for this > service. This definition is fuzzy and only leads to more confusion. I agree that all tuples are services, but one without a lacks any real indication of what service it really represents. I mean, if the presentity is unwilling or unable to disclose the , then what purpose does showing the tuple have at all? I would still propose we assign a well-defined meaning to a -less tuple, and that is, this is a tuple representing the presentity and absent of any particular means for communication. I think we all agree there is a need to be able to represent presence information that only represents the presentity (iconic representation, mood, homepage etc.). This sort of attributes don't really belong to specific service tuples as such, because they apply across the presentity's offered services. There are three options to doing this sort of thing: 1) Wrap these attributes into a , and omit the to indicate this is generic information about the presentity and not related to any particular communication channel. 2) Define a new "wrapper type", as a sibling to , e.g., that includes all presentity-related information not related to any service. 3) Include these attributes directly under the element Out of these three, 1) seems the cleanest, because it plays well with other specifications like presence authorization and partial notifications. The others would require changes elsewhere were we to adopt either one of them. Cheers, Aki > > >> >> >>> >>>> >>>> Both (1) and (2) can contain RPID and CIPID information (the latter >>>> probably only for tuples). If (2) contains RPID >>>> information, it means that it refers to the device or service. >>> >>> >>> >>> >>> Which? What would it mean when I have devices that support multiple >>> services, and a multiplicity of services that can run on a single >>> device? >> >> >> >> I'd like to determine first what the notion of device is meant to do. > > > Its meant to (1) serve as a way of correlating data together, and (2) > act as a container for data that is really about the device. > > Here's an example of a real problem I have surrounding (1). Lets say I'm > able to get some information from the PSTN about the status of a phone - > whether its on hook, off-hook, etc. I want to correlate this information > (which is associated with the device-ID for the phone), with information > about services running on that phone that I learn from PUBLISH, > REGISTER, and other means. I can't do this unless the published data > from the phone about those services indicates what devices they are on. > >> >> The presence of RPID by itself wouldn't be able to distinguish a >> service from a device, thus, it could appear in tuples of both types. > > > Where I'm at is that I think we should have an RPID element called > that appears in a tuple, which indicates a device the > service runs on. Separately, as a sibling of tuple, the PIDF doc can > have elements, which contain the device-id, but also other > device-specific data. SO, for example: > > > xmlns:local="urn:example-com:pidf-status-type" > entity="pres:someone@example.com"> > > urn:esn:76533-233374 > > open > > im:someone@example.com > > > Germany > large > little > > > > > With this, I can have a service that I can say runs on one device or > many devices, and if I include the same in multiple tuples, > I can indicate that multiple services run on the same device. > > You can have the without the bigger ; in such a > case, it ONLY serves as a correlation tool. This makes the above > document play nice with filtering techniques. The "reference" here - the > device-ID - has meaning even if the element it talks about > disappears from the document. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 11 09:45:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27459 for ; Fri, 11 Jun 2004 09:45:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYmLO-000204-Vz for simple-archive@ietf.org; Fri, 11 Jun 2004 09:45:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYmDp-0007lV-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 09:37:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYm54-0005UN-00; Fri, 11 Jun 2004 09:28:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYm55-0000hv-74; Fri, 11 Jun 2004 09:28:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUj-0001CI-7o; Fri, 11 Jun 2004 07:46:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYhgx-0003u4-1M for simple@megatron.ietf.org; Fri, 11 Jun 2004 04:47: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 EAA07551 for ; Fri, 11 Jun 2004 04:46:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYhgf-0006LE-Mx for simple@ietf.org; Fri, 11 Jun 2004 04:46:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYhfp-0005vF-00 for simple@ietf.org; Fri, 11 Jun 2004 04:46:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYhfH-0005Tp-00 for simple@ietf.org; Fri, 11 Jun 2004 04:45:31 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5B8j7bo021884; Fri, 11 Jun 2004 04:45:08 -0400 (EDT) Message-ID: <40C970FE.2080106@dynamicsoft.com> Date: Fri, 11 Jun 2004 04:44:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40C960DF.8070702@nokia.com> In-Reply-To: <40C960DF.8070702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > > ext Jonathan Rosenberg wrote: > ...snip... > >> That is, I think we shouldn't use the presence or absence of the >> contact URI in the tuple to mean that the tuple is modeling something >> fundamentally different. Rather, the absence of the contact URI means >> that the presentity is unable or unwilling to disclose the URI for >> this service. > > > This definition is fuzzy and only leads to more confusion. I think its confusing that the information that a tuple is modeling should change based on whether a contact is present or not. > I agree that > all tuples are services, but one without a lacks any real > indication of what service it really represents. I mean, if the > presentity is unwilling or unable to disclose the , then what > purpose does showing the tuple have at all? Other things in the tuple, like RPID information, indicate the nature of the service. If you don't include that kind of information, then I agree the tuple is worthless. > > I would still propose we assign a well-defined meaning to a > -less tuple, and that is, this is a tuple representing the > presentity and absent of any particular means for communication. Whilst I agreed with this initially, I now think we'd be better served by having a element. > > I think we all agree there is a need to be able to represent presence > information that only represents the presentity (iconic representation, > mood, homepage etc.). This sort of attributes don't really belong to > specific service tuples as such, because they apply across the > presentity's offered services. There are three options to doing this > sort of thing: > > 1) Wrap these attributes into a , and omit the to > indicate this is generic information about the presentity and not > related to any particular communication channel. > > 2) Define a new "wrapper type", as a sibling to , e.g., > that includes all presentity-related information not related to any > service. Right - this is the one I like. Its the most explicit. > > 3) Include these attributes directly under the element > > Out of these three, 1) seems the cleanest, because it plays well with > other specifications like presence authorization and partial > notifications. The others would require changes elsewhere were we to > adopt either one of them. I think we are going to need to make sure that the authorization stuff is aligned with the PIDF/RPID data models no matter what we do. Part of my difficulties in wrapping up the authorization spec is that we keep tripping on the "what is a tuple" issue in figuring out what kind of functions to include in the authorization policies. You raise a good point on partial notifications. Using a separate element also won't play well with that. I'd hate to force things into tuples when they don't belong, just because partial notifications doesnt know about anything but tuples. -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-bounces@ietf.org Fri Jun 11 10:09:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00795 for ; Fri, 11 Jun 2004 10:09:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYmio-00077E-8F for simple-archive@ietf.org; Fri, 11 Jun 2004 10:09:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYmY5-0004h6-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 09:58:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYmM0-00023F-00; Fri, 11 Jun 2004 09:45:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYmAN-00010j-IW; Fri, 11 Jun 2004 09:33:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUo-0001ED-6i; Fri, 11 Jun 2004 07:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYjPc-0004cZ-V3 for simple@megatron.ietf.org; Fri, 11 Jun 2004 06:37: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 GAA11416 for ; Fri, 11 Jun 2004 06:37:25 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYjPa-00079w-3M for simple@ietf.org; Fri, 11 Jun 2004 06:37:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYjOO-0006fB-00 for simple@ietf.org; Fri, 11 Jun 2004 06:36:12 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BYjNp-0006DK-00 for simple@ietf.org; Fri, 11 Jun 2004 06:35:37 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5BAZb219754 for ; Fri, 11 Jun 2004 13:35:37 +0300 (EET DST) X-Scanned: Fri, 11 Jun 2004 13:35:27 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5BAZR1l030094 for ; Fri, 11 Jun 2004 13:35:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00l8hPNV; Fri, 11 Jun 2004 13:35:25 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5BAZOH16108 for ; Fri, 11 Jun 2004 13:35:24 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Jun 2004 13:35:21 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] New version of XCAP usage for manipulating presence document contents Date: Fri, 11 Jun 2004 13:35:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17345@esebe004.ntc.nokia.com> Thread-Topic: [Simple] New version of XCAP usage for manipulating presence document contents Thread-Index: AcPvSAnlGDdWtkDYR5GSxd9IBCgMVgAoZA8QF+XUtEA= To: X-OriginalArrivalTime: 11 Jun 2004 10:35:21.0779 (UTC) FILETIME=[CC375830:01C44F9F] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Below some comments to the draft. I will send all nits directly to Markus. Page 1, first paragraph: Contains reference to RFC2026. Should be updated to RFC 3668 Section 1, introduction: This section contains quite a lot requirement/use case text. This is probably ok but I was wondering if this is really needed for WG draft? Section 5, first parapraph: " The XML [5] format of the presence information (PIDF) is defined in [3] and its extensions.=20 " Change to -> " =20 The XML [5] format of the presence information (PIDF) is defined in PIDF [3]. PIDF also defines a mechanism how presence documents can be extended. "=20 " The PIDF defines the presence information to consist of the root element 'presence' including 'tuples' which contain a mandatory status element, a communication mean specific presence attribute and other markups. "=20 Change to -> "The PIDF defines the presence information to consist of the root element 'presence'. The 'presence' element can contain 'tuple' elements which contain a mandatory status element, a communication mean specific presence attribute and other markups.=20 " Section 6: This section sound very vague. Especially when document doesn't by itself define any XML schema. It might be good to add some text explain what this computed data is. Section 7: "There are no constraints on the document beyond those described in the XML schemas and [3]. " =09 To what other schemas this section refers to than PIDF schema or what are those other schemas? Section 10: " The XML schema definition for the presence information can be found from [3] and its extensions. " Change to -> " The XML schema definition for the presence information can be found from PIDF [3]. PIDF presence document can also contain extensions like RPID [ref]. " Section 11, example: For me this example is not totally clear in what it tries to demonstrate. I think it tries to show an example what kind of presence document can be published using XCAP. However, I could also ready it as what PS should directly put into notifications which it sends to the watchers. There could be more text saying that this is the presence document provided from XCAP client to XCAP server. Section 13.1, " Description: Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of presence documents in Session Initiation Protocol (SIP) based presence systems. " Change to -> " Description: PIDF-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF based presence documents.=20 " - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext Markus.Isomaki@nokia.com > Sent: Tuesday, February 10, 2004 5:52 PM > To: simple@ietf.org > Subject: [Simple] New version of XCAP usage for manipulating=20 > presence document contents >=20 >=20 > Hi, >=20 > I have submitted a new version on the XCAP application usage=20 > for manipulating the content of PIDF presence document,=20 > previously known as XCAP usage for presence publishing.=20 >=20 > You can find it at:=20 > http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap- pidf-manipulation-usage-00.txt (Note that actually this has been approved as SIMPLE WG item, but due to my typo, it is still named as an individual draft.) The main idea of the draft is to complement SIP PUBLISH to allow the presentity to manipulate device independent "hard state" presence information. This hard state information would be fed to the presence composition process as one input alongside the PUA views published using SIP. There are no open issues as such within the draft, the updates compared to the last version were mainly about better wording. However, there is one big issue wrt. the latest discussion on SIP PUBLISH. There has been a proposal (on SIP WG list) to enhance PUBLISH solution so that PUAs would be able to learn the states set by each other and actually override such states. If this is brought forward PUBLISH will really start overlapping with the XCAP usage defined here. I will continue this discussion on SIP WG mailing list. Regards, Markus =20 _______________________________________________ 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-bounces@ietf.org Fri Jun 11 10:43:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05586 for ; Fri, 11 Jun 2004 10:43:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYnG3-0000T9-RB for simple-archive@ietf.org; Fri, 11 Jun 2004 10:43:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYn4v-0005JN-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 10:32:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYmzu-0003iq-05; Fri, 11 Jun 2004 10:27:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYmsw-0004yF-6P; Fri, 11 Jun 2004 10:19:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYmQ3-0002pw-I0; Fri, 11 Jun 2004 09:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYklv-0004e9-Gd for simple@megatron.ietf.org; Fri, 11 Jun 2004 08:04: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 HAA14355 for ; Fri, 11 Jun 2004 07:16:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYk13-0000rP-7P for simple@ietf.org; Fri, 11 Jun 2004 07:16:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYk06-0000Ph-00 for simple@ietf.org; Fri, 11 Jun 2004 07:15:10 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYjze-0007kx-00 for simple@ietf.org; Fri, 11 Jun 2004 07:14:42 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5BBEVbo021945 for ; Fri, 11 Jun 2004 07:14:31 -0400 (EDT) Message-ID: <40C99402.3090803@dynamicsoft.com> Date: Fri, 11 Jun 2004 07:14:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP List Issue 1: External Reference Scope X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This issue was raised some time ago, by Hisham I think, and has yet to be resolved. I had slides on this (and the other list issues) prepared for the interim, but we didnt get to it. The resource list schema includes an element which contains a reference to another entry. The purpose of this is to avoid entering duplicate data about a user when that user appears on multiple buddy lists. The content of this element is a reference to an element. The question is, what is the scope of this reference? Is it: 1. an HTTP URI representing an XCAP resource that is an element on this server or another server, in this domain or another domain (i.e., http://server.example.com/xcap-root/resource-lists/users/jdrosen/doc1/ ~~/resource-lists/list/entry 2. a path from the XCAP root services URI, pointing to an element on this server (i.e., "/resource-lists/users/jdrosen/doc1/ ~~/resource-lists/list/entry" 3. a path from the current document, pointing to an element in the same document (i.e., "/resource-lists/list/entry" I think doing (1) introduces all kinds of hairy issues around authorization (you'd need to define policies about who can look at specific entries in your lists) and referential integrity. I think 3 gives insufficient flexibility. I'd like to be able to have a company list of users, and define by buddy list as a series of references to that central list. As such, I'd propose 2. 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-bounces@ietf.org Fri Jun 11 10:44:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05665 for ; Fri, 11 Jun 2004 10:44:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYnGI-0000VI-Nk for simple-archive@ietf.org; Fri, 11 Jun 2004 10:44:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYn5E-0005PC-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 10:32:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYmzy-0003iq-03; Fri, 11 Jun 2004 10:27:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYmsW-0004sX-8l; Fri, 11 Jun 2004 10:19:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYmO6-0002GK-S0; Fri, 11 Jun 2004 09:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkZD-0002El-JI for simple@megatron.ietf.org; Fri, 11 Jun 2004 07:51: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 HAA15323 for ; Fri, 11 Jun 2004 07:51:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYkZD-0000t8-1h for simple@ietf.org; Fri, 11 Jun 2004 07:51:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYkXy-0000Lx-00 for simple@ietf.org; Fri, 11 Jun 2004 07:50:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYkWn-0007CJ-00 for simple@ietf.org; Fri, 11 Jun 2004 07:48:57 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5BBmkbo021957 for ; Fri, 11 Jun 2004 07:48:46 -0400 (EDT) Message-ID: <40C99C0A.5070802@dynamicsoft.com> Date: Fri, 11 Jun 2004 07:48:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i5BBmkbo021957 Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCAP List Issue 4: List URI uniqueness X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The main purpose of the resource list XML schema is to define the=20 resource lists that you can subscribe to using the SIP event extension=20 for resource lists=20 (http://www.watersprings.org/pub/id/draft-ietf-simple-event-list-04.txt). This means that the SIP URI identifying each resource list needs to be=20 unique on the server. Unfortunately, those URI exist buried within each=20 resource list document. This makes it hard to, at the time a resource=20 list is added or changed, check to see that the list URI is unique. Similarly, when a resource list server (the SIP server handling=20 SUBSCRIBE requests for the list) receives a SUBSCRIBE to a list, there=20 isn't a clear document to go to that indicates the contents of that list. In other words, the SIP URI for the resource lists is meaningful as an=20 index, but it doesnt appear anywhere in the schemas as an index. There are two solutions to this problem: Approach I: Leave it alone. Let the XCAP servers maintain this index on=20 their own. It does mean that that there isn't an easy way for the=20 resource list server to fetch the contents of the list from the XCAP=20 server in a standard way. Approach II: We can define a new application usage, which is the actual=20 set of resource list URIs you can subscribe to. There would be a single=20 instance of this document for each user. That would contain the list of=20 URIs defined by that user as subscribeable resource lists. For each URI,=20 there would be a reference into their actual hierarchy of and=20 s as defined by the current schema in the existing doc. For exampl= e: http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/ resource-lists/list[@name=3D=93co-workers=94] We would, as a result of this, remove the "subscribeable" flag from the=20 current schema, along with the URI attribute for the element. In addition to there being a single instance of a document for each=20 user, there would also be a single instance of a document for the entire=20 server. This document would be in the global tree, readable only by=20 resource lists servers. It basically contains the union of all of the=20 documents for the individual users. This would allow a resource list=20 server to do a single query to obtain the HTTP URI that defines the=20 membership of the list. For example, if an RLS got a SUBSCRIBE request=20 for sip:friends@example.com, it would do the following XCAP query to get=20 the XCAP URI pointing to the membership: GET=20 http://xcap.server.com/xcap-root/list-of-lists/global/thelist/~~/sip-uris= / list[@uri=3D"sip:friends@example.com"] and the 200 OK: 200 OK Content-Type: application/xml http://www.example.com/xcap/resource-lists/users/a/obuddies/=0B=20 resource-lists/list[@name=3D=93co-workers=94] Now it can do this: GET http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/ resource-lists/list[@name=3D=93co-workers=94] and get back: 200 OK Content-Type: application/xml Bill Doe Joe Smith Nancy Gross http://www.example.org/xcap/resource-lists/users/a/foo and the result is the list of URIs the RLS needs to subscribe to. I really like approach 2. It clearly separates the SIP activities=20 associated with a list, from the set of users that make up the list. It=20 provides a concrete place where the index of buddy lists will live, both=20 for each user and for all users. It seems to work better for ad-hoc=20 lists two. The thing carried in the body of the SUBSCRIBE or INVITE or=20 MESSAGE or whatever, which identifies the ad-hoc list, is only the=20 structure set of users. The "subscribeable" flag would make no sense in=20 that context, for example, and with this proposal, it would be removed. Note that a change to the list for a single user would need to be=20 automatically reflected in the global list by the server. I'd propose making this change. I think we need to define both=20 application usages up front, since we can't satisfy our driving=20 requirement (define a way to create buddy lists for SIP resource list=20 subscriptions) without both. I would do them both in the same document=20 however. Comments? Thanks, Jonathan R. --=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 11 10:50:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07426 for ; Fri, 11 Jun 2004 10:50:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYnMP-0001gr-CX for simple-archive@ietf.org; Fri, 11 Jun 2004 10:50:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYnEb-0007cL-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 10:42:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYn3Y-0004P0-00; Fri, 11 Jun 2004 10:30:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYmiW-0002g9-RG; Fri, 11 Jun 2004 10:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYlC3-0003IH-Rq for simple@megatron.ietf.org; Fri, 11 Jun 2004 08:31: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 HAA14476 for ; Fri, 11 Jun 2004 07:21:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYk5l-00035E-KQ for simple@ietf.org; Fri, 11 Jun 2004 07:21:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYk4l-0002dz-00 for simple@ietf.org; Fri, 11 Jun 2004 07:20:00 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYk3s-0001mk-00 for simple@ietf.org; Fri, 11 Jun 2004 07:19:04 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5BBIsbo021949 for ; Fri, 11 Jun 2004 07:18:54 -0400 (EDT) Message-ID: <40C99509.1030400@dynamicsoft.com> Date: Fri, 11 Jun 2004 07:18:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP List Issue 2: Whither URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit There was some email discussions on this some time back, but no resolution. Currently, the element has the resource uri as an attribute of the . There was a proposal on the list to make it a child, just like . So, it would look like this: sip:user@example.com Joe User The issue is, do we do this or keep the current format? I strongly believe we should keep the current format. There are two reasons: 1. It reduces the size and simplifies the structure needed. This is an issue in ad-hoc group calls or ad-hoc IM where the body of the SIP request will carry one of these things. There have been requests to keep that list flat, since nothing more than a sequence of URI is needed. 2. URI is really what we want as an index to each entry. Moving it into a child makes it hard to select an entry by URI when using XCAP. We do also have the optional "name" attribute, but I think its a mistake to have two indices, and so I want to remove that (Issue 3, email to follow). Does anyone object to keeping the current format, with uri as an attribute and not a child element? 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-bounces@ietf.org Fri Jun 11 10:50:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07492 for ; Fri, 11 Jun 2004 10:50:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYnMZ-0001iM-TE for simple-archive@ietf.org; Fri, 11 Jun 2004 10:50:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYnF2-0007ff-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 10:42:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYn3z-0004qf-00; Fri, 11 Jun 2004 10:31:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYmiX-0002ga-J0; Fri, 11 Jun 2004 10:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYlCB-0003IH-Mn for simple@megatron.ietf.org; Fri, 11 Jun 2004 08:31: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 HAA14626 for ; Fri, 11 Jun 2004 07:27:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYkBk-0005kz-IG for simple@ietf.org; Fri, 11 Jun 2004 07:27:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYkAs-0005Jr-00 for simple@ietf.org; Fri, 11 Jun 2004 07:26:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BYkAJ-0004rb-00 for simple@ietf.org; Fri, 11 Jun 2004 07:25:43 -0400 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5BBPWbo021952 for ; Fri, 11 Jun 2004 07:25:32 -0400 (EDT) Message-ID: <40C99698.3070609@dynamicsoft.com> Date: Fri, 11 Jun 2004 07:25:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP List Issue 3: Name and URI indices X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Currently, the resource list format has two attributes for each . The are the optional name, and mandatory URI parameter. The name exists solely as an alternative index useful for XCAP selection of entries. However, do we really need TWO indices? The main concern around using the URI as an index is that URI comparisons are more compelx than just string match, and if we use the URI as an index for XCAP selection, the element would be selected based on string equality (case sensitive, I believe). However, its possible for two URI to be unequal by case sensitive string comparison, and equal by URI equality. More interestingly, I think it is the case that if two URI are equal by case sensitive string compare, then they will also be equal by URI comparison rules. The implication is that I will always be able to select the entry I want (i.e., there won't be ambiguity), but the XCAP rules may allow me to have two entries that have the same URI by URi equality rules, just because they differ by case sensitive string comparison. I don't think thats a particularly bad limitation (indeed, one might even argue that its a feature). As such, I'd propose to drop the name attribute entirely. Note that the specification does need to also clarify that each has to have a unique uri attribute amongst its siblings. It doesnt say that now. This means that the server will reject, with a 409, a request to add an if its uri attribute is not unique. -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-bounces@ietf.org Fri Jun 11 10:58:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08419 for ; Fri, 11 Jun 2004 10:58:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYnUC-0004Wl-II for simple-archive@ietf.org; Fri, 11 Jun 2004 10:58:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYnPf-0002zN-00 for simple-archive@ietf.org; Fri, 11 Jun 2004 10:53:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYnJK-00013F-00; Fri, 11 Jun 2004 10:47:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYn98-0006ZY-Op; Fri, 11 Jun 2004 10:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYmpU-0001Zx-UU; Fri, 11 Jun 2004 10:16:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYm6b-0004aZ-RK for simple@megatron.ietf.org; Fri, 11 Jun 2004 09:30: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 JAA25253 for ; Fri, 11 Jun 2004 09:29:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYm6b-0005lF-54 for simple@ietf.org; Fri, 11 Jun 2004 09:30:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYlxG-0003Ic-00 for simple@ietf.org; Fri, 11 Jun 2004 09:20:23 -0400 Received: from viap106.atea.be ([194.78.143.106] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1BYlk0-0000F5-00 for simple@ietf.org; Fri, 11 Jun 2004 09:06:40 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JMT29GSM; Fri, 11 Jun 2004 15:06:09 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jun 2004 15:06:09 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A428890B1E283C@hrtades2.atea.be> From: Biot Olivier To: Simple WG Subject: RE: [Simple] XCAP Issue 5 Interim Summary: selecting multiple ele ments Date: Fri, 11 Jun 2004 15:06:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Wouldn't it be simpler to use HTTP POST for multiple insertions as idempotence cannot be guaranteed? Additionally, atomic operations could be implemented by using HTTP POST and some "envelope" media type instead of the purely Etag-based approach as described today. The HTTP OPTIONS mechanism can be used to query the capabilities of an XCAP server for a given URI/URN. The Allow header in the response will tell the XCAP client which HTTP operations are allowed, and the Accept header can enumerate the accepted media types (e.g., the "envelope"). Doing so will allow the definition of an interoperable XCAP extension, and this way we can avoid the multiple insertions idempotence dilemma in the baseline XCAP spec. Any comments? Regards, Olivier |-----Original Message----- |From: Joel M. Halpern | | |I think leaving out multiple inserts, and telling people how |to cope with |the absence is MUCH better than the complications we are going |to get by |trying to include multiple inserts. | |Thank you, |Joel | |At 02:33 AM 6/10/2004 -0400, Jonathan Rosenberg wrote: |>[problem statement with non idempotent multiple insert] |> |>[Proposals for enforcing idempotentence] |>.... |>[Suggestion that we leave out multiple inserts.] |>I suggested that I could include some guidelines on schema |design to avoid |>the need for mutliple insertions. There seemed to be support for this |>position. The guidelines I will include are basically this: |> |>[Guidelines for avoiding the need for multiple inserts.] |> |>Any objections? |> |>Thanks, |>Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 13 21:12:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14791 for ; Sun, 13 Jun 2004 21:12:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZg1j-0007LP-W9 for simple-archive@ietf.org; Sun, 13 Jun 2004 21:12:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZg0n-00077O-00 for simple-archive@ietf.org; Sun, 13 Jun 2004 21:11:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZg0J-0006sg-00; Sun, 13 Jun 2004 21:11:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZfmz-0000wp-4v; Sun, 13 Jun 2004 20:57:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZfl3-0000nO-U9 for simple@megatron.ietf.org; Sun, 13 Jun 2004 20:55: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 UAA14293 for ; Sun, 13 Jun 2004 20:55:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZfl2-0003eQ-6G for simple@ietf.org; Sun, 13 Jun 2004 20:55:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZfk3-0003RS-00 for simple@ietf.org; Sun, 13 Jun 2004 20:54:28 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BZfj6-0003EK-00 for simple@ietf.org; Sun, 13 Jun 2004 20:53:28 -0400 Received: from panther.cs.columbia.edu (IDENT:sn4sMHrRNA+Zn7y8oiMEpiswIkwVf1aR@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5E0rPfq011999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 13 Jun 2004 20:53:25 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5E0rNHs023754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 13 Jun 2004 20:53:24 -0400 Message-ID: <40CCF6FE.1050405@cs.columbia.edu> Date: Sun, 13 Jun 2004 20:53:18 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> In-Reply-To: <40C78CE9.6010507@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.13.103610 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Trying to catch up; since the original was already beyond one screen, I'll split the response. > I've come to the conclusion that tuples are always services, period. See > more below. I gather we agree on that aspect. > Just because we can't always be clear as to what's a device, and what's > not, doesnt mean that its not useful to say that something is a device. > Its useful from a correlation perspective, as you point out below, but I > think it acts as a natural conduit for many pieces of information that > are inherently about the *device*, and not the service or presentity. > Geographic location and device capabilities (screen size, for example) > are the most obvious ones. Rather than trying to make talmudic device distinctions that imply certain common characteristics, why can't we simply group tuples by properties, saying that certain groups of tuples happen to share a property? This also avoids the problem that certain things that could be considered a device share on property (location), but not another (screen size). Picture a composite gadget that cables together plastic boxes with different displays - they have to be on one human body, but they each have their own display. I think one of the fundamental design assumptions in SIP is that we want to be explicit, rather than implicit about protocol properties. Don't infer things by labeling, but rather label them as such. > I'd take this one step further, and say that what we want is the ability > for a tuple to indicate a multiplicity of , indicating that > it runs on those device(s). A device ID is a meaningful identifier, in > that it represents an indentifier for that device that other components > know about, and would choose to identify the same device. In the case of > a cell phone, this might be the ESN for example. Again, I don't see the need for transforming our eternal "what is a tuple" discussion into an equally entertaining, but probably best left to FCC lawyers, discussion of "what is a device". Like tuples, it's the 80% that are easy and the 20% that yield interminable email discussions. > > It doesnt. However, if we believe that it should be OK to have a single > tuple, and that tuple represents the union of my service characteristics > (this is Brian's presentity view), then we have this problem > irregardless of whether you like the or not. I would propose > that, if you want to indicate availability for communications across a > variety of services, and those services can't be represented by a single > URI, then you could omit the URI. Indeed - no point distributing useless URIs that just insinuate that there might be a there there. > Its meant to (1) serve as a way of correlating data together, and (2) > act as a container for data that is really about the device. Since we have difficulty defining clearly what a device is, I'm not sure this helps us along - this can easily become a circular definition. >> The presence of RPID by itself wouldn't be able to distinguish a >> service from a device, thus, it could appear in tuples of both types. > > > Where I'm at is that I think we should have an RPID element called > that appears in a tuple, which indicates a device the > service runs on. Separately, as a sibling of tuple, the PIDF doc can > have elements, which contain the device-id, but also other > device-specific data. SO, for example: > > > xmlns:local="urn:example-com:pidf-status-type" > entity="pres:someone@example.com"> > > urn:esn:76533-233374 > > open > > im:someone@example.com > > > Germany > large > little > > > > > With this, I can have a service that I can say runs on one device or > many devices, and if I include the same in multiple tuples, > I can indicate that multiple services run on the same device. Again, why not simply say "this set of services is at the same location" or (and independently) "this set of services shares a screen", etc. Describing the location separately from the tuple means that I now have to be careful to remove the if all of my corresponding tuples have been filtered out, as I may or may not want to reveal location information in that case. If I want to remove filtering service tuples from location information, it seems to make more sense to define a top-level location item that I can reference from each service tuple. After all, for location it doesn't matter whether I have a collection of BlueTooth-connected devices or a single piece of plastic. For the other items, I'm not sure why replicating, say, battery information across services is a big deal. What harm is done if I have large low large low This seems simpler, at a modest cost of replication. > > You can have the without the bigger ; in such a > case, it ONLY serves as a correlation tool. This makes the above > document play nice with filtering techniques. The "reference" here - the > device-ID - has meaning even if the element it talks about > disappears from the document. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 13 21:25:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15137 for ; Sun, 13 Jun 2004 21:25:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZgE6-0002M8-Uh for simple-archive@ietf.org; Sun, 13 Jun 2004 21:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZgDD-00029B-00 for simple-archive@ietf.org; Sun, 13 Jun 2004 21:24:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZgCs-0001wO-00; Sun, 13 Jun 2004 21:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZg9E-0004ZV-LD; Sun, 13 Jun 2004 21:20:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZg7H-0004I3-V9 for simple@megatron.ietf.org; Sun, 13 Jun 2004 21:18: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 VAA14959 for ; Sun, 13 Jun 2004 21:18:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZg7G-0000qU-5N for simple@ietf.org; Sun, 13 Jun 2004 21:18:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZg6F-0000bw-00 for simple@ietf.org; Sun, 13 Jun 2004 21:17:23 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BZg5G-0000Ow-00 for simple@ietf.org; Sun, 13 Jun 2004 21:16:22 -0400 Received: from panther.cs.columbia.edu (IDENT:T6jHEAZ4Rgv4zrhn0lNsZsKwukMX0bPL@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5E1GHfq018431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 13 Jun 2004 21:16:17 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5E1GGHs026262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 13 Jun 2004 21:16:16 -0400 Message-ID: <40CCFC5A.1040603@cs.columbia.edu> Date: Sun, 13 Jun 2004 21:16:10 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40C960DF.8070702@nokia.com> In-Reply-To: <40C960DF.8070702@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.13.103610 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: ext Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > This definition is fuzzy and only leads to more confusion. I agree that > all tuples are services, but one without a lacks any real > indication of what service it really represents. I mean, if the > presentity is unwilling or unable to disclose the , then what > purpose does showing the tuple have at all? I guess you could call it a tease - I have the capability, but I won't tell you how to get to it :-) > > I would still propose we assign a well-defined meaning to a > -less tuple, and that is, this is a tuple representing the > presentity and absent of any particular means for communication. > > I think we all agree there is a need to be able to represent presence > information that only represents the presentity (iconic representation, > mood, homepage etc.). This sort of attributes don't really belong to > specific service tuples as such, because they apply across the > presentity's offered services. There are three options to doing this > sort of thing: > > 1) Wrap these attributes into a , and omit the to > indicate this is generic information about the presentity and not > related to any particular communication channel. > > 2) Define a new "wrapper type", as a sibling to , e.g., > that includes all presentity-related information not related to any > service. > > 3) Include these attributes directly under the element And maybe another one: (4) label a tuple with some "this applies to the presentity" label (and thereby have these apply to all other tuples), regardless of whether there is a contact URI or not I'm not particularly fond of this one. > > Out of these three, 1) seems the cleanest, because it plays well with > other specifications like presence authorization and partial > notifications. The others would require changes elsewhere were we to > adopt either one of them. (2) still has the problem that per-tuple override isn't particularly clean, syntactically. Only (3) clearly indicates an inheritance relationship, i.e., a tuple could override the generic RPID information if it has contradictory information. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 13 21:32:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15429 for ; Sun, 13 Jun 2004 21:32:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZgKr-0003uC-Iw for simple-archive@ietf.org; Sun, 13 Jun 2004 21:32:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZgK3-0003hc-00 for simple-archive@ietf.org; Sun, 13 Jun 2004 21:31:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZgJg-0003Tr-00; Sun, 13 Jun 2004 21:31:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZgFv-0005UU-Cp; Sun, 13 Jun 2004 21:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZgAB-0004iE-Ms for simple@megatron.ietf.org; Sun, 13 Jun 2004 21:21: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 VAA15049 for ; Sun, 13 Jun 2004 21:21:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZgAA-0001VR-0W for simple@ietf.org; Sun, 13 Jun 2004 21:21:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZg9C-0001Hc-00 for simple@ietf.org; Sun, 13 Jun 2004 21:20:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BZg8F-00013q-00 for simple@ietf.org; Sun, 13 Jun 2004 21:19:27 -0400 Received: from panther.cs.columbia.edu (IDENT:s1DWerW/CRvoAlWha3ajVEOAqFHvoVTl@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5E1JPfq019180 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 13 Jun 2004 21:19:25 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5E1JOHs026660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 13 Jun 2004 21:19:24 -0400 Message-ID: <40CCFD17.2090001@cs.columbia.edu> Date: Sun, 13 Jun 2004 21:19:19 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40C960DF.8070702@nokia.com> <40C970FE.2080106@dynamicsoft.com> In-Reply-To: <40C970FE.2080106@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.13.103610 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > I think we are going to need to make sure that the authorization stuff > is aligned with the PIDF/RPID data models no matter what we do. Part of > my difficulties in wrapping up the authorization spec is that we keep > tripping on the "what is a tuple" issue in figuring out what kind of > functions to include in the authorization policies. > > You raise a good point on partial notifications. Using a separate > element also won't play well with that. I'd hate to force > things into tuples when they don't belong, just because partial > notifications doesnt know about anything but tuples. The more separate "tables" we have (and this is essentially what we're doing), the more complicated maintaining referential consistency becomes, where either pointers point to non-existent descriptions or there are orphans, i.e., elements that aren't referenced by anything. We had this discussion before, many moons ago: once we allow something like the element or a contact-less tuple, we'd have to decide whether a tuple could override all or part of that information. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 03:34:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11250 for ; Mon, 14 Jun 2004 03:34:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZlzZ-0000pr-1k for simple-archive@ietf.org; Mon, 14 Jun 2004 03:34:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZlyk-0000b7-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 03:34:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZly5-0000JE-00; Mon, 14 Jun 2004 03:33:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZlra-0007ST-TP; Mon, 14 Jun 2004 03:26:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZlfA-0005Gf-F7 for simple@megatron.ietf.org; Mon, 14 Jun 2004 03:13: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 DAA10276 for ; Mon, 14 Jun 2004 03:13:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZlf8-0003RQ-21 for simple@ietf.org; Mon, 14 Jun 2004 03:13:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZle4-0003DN-00 for simple@ietf.org; Mon, 14 Jun 2004 03:12:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BZldf-000313-00 for simple@ietf.org; Mon, 14 Jun 2004 03:12:16 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5E7BwN01005; Mon, 14 Jun 2004 10:12:04 +0300 (EET DST) X-Scanned: Mon, 14 Jun 2004 10:11:51 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5E7BpE4009745; Mon, 14 Jun 2004 10:11:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003QgJdD; Mon, 14 Jun 2004 10:11:50 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5E7BoH20175; Mon, 14 Jun 2004 10:11:50 +0300 (EET DST) Received: from nokia.com ([172.21.40.141]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Jun 2004 10:11:29 +0300 Message-ID: <40CD4FA1.9030305@nokia.com> Date: Mon, 14 Jun 2004 10:11:29 +0300 From: Miguel 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-es MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 2: Whither URI References: <40C99509.1030400@dynamicsoft.com> In-Reply-To: <40C99509.1030400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2004 07:11:29.0971 (UTC) FILETIME=[D0BAD030:01C451DE] Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan: One issue that makes me think a child element will have advantages is the case when there are several URIs representing an entry, for instance a sip and press or im URIs. If you represent the URI as an attribute then you can't have repetitions of the same attribute. However, if you represent the URI as an element you can have repetitions, for example: sip:user@example.com pres:user@example.com Joe User If you have an attribute, you will need to create a new entry per URI, and that might not be so efficient. - Miguel Jonathan Rosenberg wrote: > There was some email discussions on this some time back, but no resolution. > > Currently, the element has the resource uri as an attribute of > the . There was a proposal on the list to make it a child, just > like . So, it would look like this: > > > sip:user@example.com > Joe User > > > The issue is, do we do this or keep the current format? > > I strongly believe we should keep the current format. There are two > reasons: > > 1. It reduces the size and simplifies the structure needed. This is an > issue in ad-hoc group calls or ad-hoc IM where the body of the SIP > request will carry one of these things. There have been requests to keep > that list flat, since nothing more than a sequence of URI is needed. > > 2. URI is really what we want as an index to each entry. Moving it into > a child makes it hard to select an entry by URI when using XCAP. We do > also have the optional "name" attribute, but I think its a mistake to > have two indices, and so I want to remove that (Issue 3, email to follow). > > Does anyone object to keeping the current format, with uri as an > attribute and not a child element? > > Thanks, > Jonathan R. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 04:16:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13418 for ; Mon, 14 Jun 2004 04:16:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZmdY-000357-6F for simple-archive@ietf.org; Mon, 14 Jun 2004 04:16:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZmcl-0002oY-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 04:15:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZmby-0002UI-00; Mon, 14 Jun 2004 04:14:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZmUL-0007Lb-4F; Mon, 14 Jun 2004 04:06:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZmI3-0002ia-5W for simple@megatron.ietf.org; Mon, 14 Jun 2004 03:53:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12127 for ; Mon, 14 Jun 2004 03:53:57 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZmI0-0005N5-SK for simple@ietf.org; Mon, 14 Jun 2004 03:53:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZmH7-00058O-00 for simple@ietf.org; Mon, 14 Jun 2004 03:53:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BZmGb-0004sS-00 for simple@ietf.org; Mon, 14 Jun 2004 03:52:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5E7qSN27502; Mon, 14 Jun 2004 10:52:28 +0300 (EET DST) X-Scanned: Mon, 14 Jun 2004 10:52:20 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5E7qKEo010106; Mon, 14 Jun 2004 10:52:20 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00hc1DzV; Mon, 14 Jun 2004 10:52:19 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5E7qEH16981; Mon, 14 Jun 2004 10:52:14 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Jun 2004 10:52:13 +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] XCAP List Issue 1: External Reference Scope Date: Mon, 14 Jun 2004 10:52:13 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C5C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP List Issue 1: External Reference Scope Thread-Index: AcRPv1qKd5seo9hCTFGOlheq7KblbgCJQdEA To: , X-OriginalArrivalTime: 14 Jun 2004 07:52:13.0732 (UTC) FILETIME=[81532640:01C451E4] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 2 is OK, but you still need some text defining the behaviour when the = referenced list cannot be accessed (has been removed, etc). Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 11.June.2004 14:14 > To: Simple WG > Subject: [Simple] XCAP List Issue 1: External Reference Scope >=20 >=20 > This issue was raised some time ago, by Hisham I think, and=20 > has yet to=20 > be resolved. I had slides on this (and the other list issues)=20 > prepared=20 > for the interim, but we didnt get to it. >=20 > The resource list schema includes an element=20 > which contains=20 > a reference to another entry. The purpose of this is to avoid=20 > entering=20 > duplicate data about a user when that user appears on multiple buddy=20 > lists. The content of this element is a reference to an=20 > element.=20 > The question is, what is the scope of this reference? Is it: >=20 > 1. an HTTP URI representing an XCAP resource that is an=20 > element=20 > on this server or another server, in this domain or another domain=20 > (i.e.,=20 > http://server.example.com/xcap-root/resource-lists/users/jdrosen/doc1/ > ~~/resource-lists/list/entry >=20 >=20 > 2. a path from the XCAP root services URI, pointing to an =20 > element on this server (i.e., "/resource-lists/users/jdrosen/doc1/ > ~~/resource-lists/list/entry" >=20 > 3. a path from the current document, pointing to an =20 > element in=20 > the same document (i.e., "/resource-lists/list/entry" >=20 >=20 > I think doing (1) introduces all kinds of hairy issues around=20 > authorization (you'd need to define policies about who can look at=20 > specific entries in your lists) and referential integrity. I think 3=20 > gives insufficient flexibility. I'd like to be able to have a company=20 > list of users, and define by buddy list as a series of references to=20 > that central list. As such, I'd propose 2. >=20 > Comments? >=20 > Thanks, > Jonathan R. > --=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-bounces@ietf.org Mon Jun 14 04:30:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14186 for ; Mon, 14 Jun 2004 04:30:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZmrb-0006sc-0e for simple-archive@ietf.org; Mon, 14 Jun 2004 04:30:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZmqc-0006c5-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 04:29:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZmpZ-0006Ae-00; Mon, 14 Jun 2004 04:28:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZmiZ-0003yX-By; Mon, 14 Jun 2004 04:21:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZmZJ-0002GL-QY for simple@megatron.ietf.org; Mon, 14 Jun 2004 04:11: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 EAA13134 for ; Mon, 14 Jun 2004 04:11:48 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZmZH-0001vA-GM for simple@ietf.org; Mon, 14 Jun 2004 04:11:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZmYH-0001fy-00 for simple@ietf.org; Mon, 14 Jun 2004 04:10:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BZmXK-0001RW-00 for simple@ietf.org; Mon, 14 Jun 2004 04:09:46 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5E89iJ04785; Mon, 14 Jun 2004 11:09:45 +0300 (EET DST) X-Scanned: Mon, 14 Jun 2004 11:09:37 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5E89brP015979; Mon, 14 Jun 2004 11:09:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00QBpYvV; Mon, 14 Jun 2004 11:09:35 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5E89ZH26755; Mon, 14 Jun 2004 11:09:35 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Jun 2004 11:09:35 +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] XCAP List Issue 2: Whither URI Date: Mon, 14 Jun 2004 11:09:35 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C5D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP List Issue 2: Whither URI Thread-Index: AcRPwMKoyB0dmVgDRhKdmL+Lrj/DcwCJYkKg To: , X-OriginalArrivalTime: 14 Jun 2004 08:09:35.0148 (UTC) FILETIME=[EE0E9EC0:01C451E6] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The reason I suggested this a while ago is that I believed it is much = cleaner to represent the entry characteristics all at the same level = (child elements), but I don't feel so strongly about it. /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 11.June.2004 14:19 > To: Simple WG > Subject: [Simple] XCAP List Issue 2: Whither URI >=20 >=20 > There was some email discussions on this some time back, but=20 > no resolution. >=20 > Currently, the element has the resource uri as an=20 > attribute of=20 > the . There was a proposal on the list to make it a=20 > child, just=20 > like . So, it would look like this: >=20 > > sip:user@example.com > Joe User > >=20 > The issue is, do we do this or keep the current format? >=20 > I strongly believe we should keep the current format. There=20 > are two reasons: >=20 > 1. It reduces the size and simplifies the structure needed.=20 > This is an=20 > issue in ad-hoc group calls or ad-hoc IM where the body of the SIP=20 > request will carry one of these things. There have been=20 > requests to keep=20 > that list flat, since nothing more than a sequence of URI is needed. >=20 > 2. URI is really what we want as an index to each entry.=20 > Moving it into=20 > a child makes it hard to select an entry by URI when using=20 > XCAP. We do=20 > also have the optional "name" attribute, but I think its a mistake to=20 > have two indices, and so I want to remove that (Issue 3,=20 > email to follow). >=20 > Does anyone object to keeping the current format, with uri as an=20 > attribute and not a child element? >=20 > Thanks, > Jonathan R. > --=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-bounces@ietf.org Mon Jun 14 05:20:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16059 for ; Mon, 14 Jun 2004 05:20:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZne6-0003Hi-EA for simple-archive@ietf.org; Mon, 14 Jun 2004 05:20:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZndN-00033a-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 05:20:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZncf-0002lk-00; Mon, 14 Jun 2004 05:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZnbQ-00034Y-Sz; Mon, 14 Jun 2004 05:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZnZD-0002mz-KB for simple@megatron.ietf.org; Mon, 14 Jun 2004 05:15: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 FAA15733 for ; Mon, 14 Jun 2004 05:15:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZnZB-0001yY-3p for simple@ietf.org; Mon, 14 Jun 2004 05:15:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZnYP-0001jj-00 for simple@ietf.org; Mon, 14 Jun 2004 05:14:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BZnXR-0001FO-00 for simple@ietf.org; Mon, 14 Jun 2004 05:13:57 -0400 Received: from dynamicsoft.com ([63.113.46.31]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5E9Djbo023339; Mon, 14 Jun 2004 05:13:46 -0400 (EDT) Message-ID: <40CD6C2B.2080508@dynamicsoft.com> Date: Mon, 14 Jun 2004 05:13:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dror Shlomo References: <8993B20049600A40B0AEAFD6F736C9DF538C92@MHAIFA.followap.com> In-Reply-To: <8993B20049600A40B0AEAFD6F736C9DF538C92@MHAIFA.followap.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i5E9Djbo023339 Content-Transfer-Encoding: quoted-printable Cc: Sharon Fridman , simple@ietf.org, dwillis@dynamicsoft.com Subject: [Simple] Re: issue regarding SUBSCRIBE method X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable inline. Dror Shlomo wrote: > Hi, >=20 > =20 >=20 > I have a question about the SUBSCRIBE method as described in rfc2365 an= d=20 > in draft-ietf-simple-presence-10.txt >=20 > =20 >=20 > From rfc3265: >=20 > =20 >=20 > *3.1.2. Identification of Subscribed Events and Event Classes* >=20 > *=85* >=20 > *The "Event" header MAY also contain an "id" parameter.* >=20 > * This "id" parameter, if present, contains an opaque token which* >=20 > * identifies the specific subscription within a dialog.*=20 >=20 > =20 >=20 > And also >=20 > =20 >=20 > *3.1.4.1. Requesting a Subscription* >=20 > *=85* >=20 > *A SUBSCRIBE request MAY include an "id" parameter in its "Event"* >=20 > * header to allow differentiation between multiple subscriptions in t= he* >=20 > * same dialog.* >=20 > =20 >=20 > My question is: >=20 > =20 >=20 > 1. Are multiple subscription in the same dialog allowed in a presenc= e > event package? Yes. > 2. If so, how do I create the first dialog (SUBSCRIBE? INVITE? BOTH?= ) You can use any dialog creating request, so either SUBSCRIBE or INVITE.=20 Of course, if you use INVITE, that will create a call in addition to the=20 SIP dialog. > 3. And most importantly, can I subscribe with in the same dialog > several times, each with a different From and To URIs? No. The dialog sharing is meant only to address the case where you want=20 to direct several subscriptions to your peer in an existing dialog. If=20 you want a way for doing list subscriptions, try this: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt I'll also note that lots of problems have been found with dialog sharing=20 since it was proposed in RFC3261, and better techniques for providing=20 this function have been developed (most notably GRUU). > 4. Is the example correct regarding the questions above and > considered as multiple subscriptions with in the same dialog? >=20 > =20 >=20 > Example: >=20 > =20 >=20 > =20 >=20 > UAC UAS >=20 > =20 >=20 > ------------SUBSCRIBE -------=E0 >=20 > From: sip:bob; tag=3D123 >=20 > To: sip:alice; >=20 > Event: presence; id=3D1 >=20 > Call-ID: 2010@watcherhost.example.com >=20 > =20 >=20 > =DF---------200 OK ----------------- >=20 > =20 >=20 > ------------SUBSCRIBE -------=E0 >=20 > From: sip:bob; tag=3D123 >=20 > To: sip:john; tag=3D234 >=20 > Event: presence; id=3D1 >=20 > Call-ID: 2010@watcherhost.example.com No. You can't change the To. -Jonathan R. --=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 20:51:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17129 for ; Mon, 14 Jun 2004 20:51:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba2B7-00067r-Si for simple-archive@ietf.org; Mon, 14 Jun 2004 20:51:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba2AF-0005nI-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 20:51:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba29Z-0005Nx-00; Mon, 14 Jun 2004 20:50:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba1TJ-0000hF-9i; Mon, 14 Jun 2004 20:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba0CJ-0007ql-SD for simple@megatron.ietf.org; Mon, 14 Jun 2004 18:45: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 SAA09738 for ; Mon, 14 Jun 2004 18:44:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba0CI-0004X5-BH for simple@ietf.org; Mon, 14 Jun 2004 18:44:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba0B4-00046y-00 for simple@ietf.org; Mon, 14 Jun 2004 18:43:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Ba090-0003Ca-00 for simple@ietf.org; Mon, 14 Jun 2004 18:41:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2004 18:42:07 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5EMf2c3016209; Mon, 14 Jun 2004 18:41:02 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJK17650; Mon, 14 Jun 2004 18:41:01 -0400 (EDT) Message-ID: <40CE297C.7050702@cisco.com> Date: Mon, 14 Jun 2004 18:41:01 -0400 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: Jonathan Rosenberg Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Trying to catch up. Won't try to respond to each message in the thread. I have the sense (as Henning also seems to) that we are at risk of replacing "what is a tuple" with "what is a device". Personally, I have always largely considered a device synonymous with a unique contact address. This of course doesn't always map to a physical device, but it maps to a "virtual device", which is the only thing that is helpful to the watcher in an operational way. If we introduce explicit device ids, then we end up with the following possible situations: 1) a tuple, and the contact address it contains, is 1:1 with a device 2) several tuples, with distinct contact addresses, are associated with the same device 3) a tuple, and the contact address it contains, is associated with several devices 4) several tuples contain the same contact address 5) a tuple has no contact address 6) a tuple is associated with no device Of those, 4-6 present issues I don't want to talk about right now. I'm only going to discuss 1-3. Case (1) is pretty easy to understand. You can consider the address to represent either a service or a device. In case (2) you know some additional information, but it isn't clear to me how valuable that information is. You would like to draw inferences, but most of them aren't safe. Physical location is probably safe by any reasonable definition of device. But that is easily dealt with by replicating location information. Simultaneous availability is I think what people would like to infer. But that isn't always a good assumption. The nature of the device may prevent me from using both capabilities simultaneously. At best, I think device might be useful here in the PUBLISHed tuples so it could be used by aggregation rules that also know the nature of the device and can make the appropriate inferences. For instance the rules might decide to replicate location information from a tuple that had it to tuples for the same device that don't have it, and give precedence in some way when multiple tuples provide location for the same device. But device info in the resulting tuples that are delivered to subscribers would be much less interesting and perhaps should be suppressed. Case (3) is just Brian's original approach, restated. I had problems with it then, and I have problems with it now. It just isn't very clear what this means operationally. Does it mean that the capabilities described by the tuple are partitioned among the devices, or replicated on each of the devices? Are requests presented to the address serviced by one device, or by a combination of the devices? Without knowing the answers to these questions, this kind of presence status is pretty useless. And even if the questions are answered, only some answers lead to useful results. In particular, if the capabilities are partitioned among the devices, and requests are serviced by only a single device then the presence is pretty much useless. If the capabilities are partitioned but all the devices may participate in servicing a request, then its useful but the device information itself is useless. The the capabilities are replicated on all devices and a single device services a request, again I have useful presence information but knowing the device info isn't helpful. And I just can't make any sense of the situation where capabilities are replicated and requests are serviced by a combination of devices. So the bottom line is that I can't find any situation in which case (3) is useful. So, I guess I can support including device id in PUBLISH, for use in aggregation, with restriction that there is at most one device id per tuple. Paul Jonathan Rosenberg wrote: > inline. > > Henning Schulzrinne wrote: > >> >> >> Jonathan Rosenberg wrote: >> >>> The problem here is that a device can host a multiplicity of services >>> (my cell phone), each of which may have radically different URI, and >>> that a device itself is not well described by a single contact address. >> >> >> >> I've never been particularly enamored with the notion of devices being >> represented as tuples, in the sense of one device = one tuple. Maybe a >> better way to look at this is that tuples with contacts are *always* >> services. > > > I've come to the conclusion that tuples are always services, period. See > more below. > > From a reachability perspective, as to whether I have three > >> plastic gadgets on my belt connected by BlueTooth, or whether they are >> all in a single Treo-like device or whether they all have a separate >> network interfaces seems to matter very little, particularly since (as >> was discussed in the interim) it's hard to make very clear >> delineations as to what counts as a single device. > > > Just because we can't always be clear as to what's a device, and what's > not, doesnt mean that its not useful to say that something is a device. > Its useful from a correlation perspective, as you point out below, but I > think it acts as a natural conduit for many pieces of information that > are inherently about the *device*, and not the service or presentity. > Geographic location and device capabilities (screen size, for example) > are the most obvious ones. > > >> >> The only reason I can see that the notion of a device matters is to >> estimate whether two services are pretty much guaranteed to be >> available at the same time, by the same person. > > > Yes, correlation is a big part of the need. Its not the only one. > >> (As opposed to having one service be left on the dresser at home and >> one carried by the user.) A simple, unique and non-reachable >> identifier that indicates this reachability and locational unity, as >> the token, does this. > > > I'd take this one step further, and say that what we want is the ability > for a tuple to indicate a multiplicity of , indicating that > it runs on those device(s). A device ID is a meaningful identifier, in > that it represents an indentifier for that device that other components > know about, and would choose to identify the same device. In the case of > a cell phone, this might be the ESN for example. > >> >>> >>> However, you say something important in your suggestion, which is >>> "contact-equipped tuples can be either devices (which also is an >>> instance of a service)". My proposal for what "device view" means was >>> that you have a tuple that represents all of the services available >>> on a particular device, by doing a pivot operation on that device. In >>> that way, the service tuple "represents" a device, in that I'm trying >>> to have a single tuple for each device. However, the tuple is still >>> fundamentally describing a service, NOT a device. >> >> >> >> We seem to be arriving at similar conclusions through slightly >> different paths. My disagreement is that I don't see the possibility >> of having a single tuple represent all services on a device, given >> that, as you say, they may not have a single reachable protocol URI >> (sip, mailto, etc.) that can represent them all. I don't see how >> >> >> urn:device:1234566 >> >> >> helps any, unless we assume that there is a URN resolution mechanism >> that actually translates this, ENUM-style, into a set of services. > > > It doesnt. However, if we believe that it should be OK to have a single > tuple, and that tuple represents the union of my service characteristics > (this is Brian's presentity view), then we have this problem > irregardless of whether you like the or not. I would propose > that, if you want to indicate availability for communications across a > variety of services, and those services can't be represented by a single > URI, then you could omit the URI. > > That is, I think we shouldn't use the presence or absence of the contact > URI in the tuple to mean that the tuple is modeling something > fundamentally different. Rather, the absence of the contact URI means > that the presentity is unable or unwilling to disclose the URI for this > service. > > >> >> >>> >>>> >>>> Both (1) and (2) can contain RPID and CIPID information (the latter >>>> probably only for tuples). If (2) contains RPID >>>> information, it means that it refers to the device or service. >>> >>> >>> >>> >>> Which? What would it mean when I have devices that support multiple >>> services, and a multiplicity of services that can run on a single >>> device? >> >> >> >> I'd like to determine first what the notion of device is meant to do. > > > Its meant to (1) serve as a way of correlating data together, and (2) > act as a container for data that is really about the device. > > Here's an example of a real problem I have surrounding (1). Lets say I'm > able to get some information from the PSTN about the status of a phone - > whether its on hook, off-hook, etc. I want to correlate this information > (which is associated with the device-ID for the phone), with information > about services running on that phone that I learn from PUBLISH, > REGISTER, and other means. I can't do this unless the published data > from the phone about those services indicates what devices they are on. > >> >> The presence of RPID by itself wouldn't be able to distinguish a >> service from a device, thus, it could appear in tuples of both types. > > > Where I'm at is that I think we should have an RPID element called > that appears in a tuple, which indicates a device the > service runs on. Separately, as a sibling of tuple, the PIDF doc can > have elements, which contain the device-id, but also other > device-specific data. SO, for example: > > > xmlns:local="urn:example-com:pidf-status-type" > entity="pres:someone@example.com"> > > urn:esn:76533-233374 > > open > > im:someone@example.com > > > Germany > large > little > > > > > With this, I can have a service that I can say runs on one device or > many devices, and if I include the same in multiple tuples, > I can indicate that multiple services run on the same device. > > You can have the without the bigger ; in such a > case, it ONLY serves as a correlation tool. This makes the above > document play nice with filtering techniques. The "reference" here - the > device-ID - has meaning even if the element it talks about > disappears from the document. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 20:55:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17415 for ; Mon, 14 Jun 2004 20:55:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba2Es-0007UO-EV for simple-archive@ietf.org; Mon, 14 Jun 2004 20:55:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba2E1-0007AC-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 20:54:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba2D8-0006ly-00; Mon, 14 Jun 2004 20:53:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba1UT-00017L-Nt; Mon, 14 Jun 2004 20:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba0Y2-00021L-0L for simple@megatron.ietf.org; Mon, 14 Jun 2004 19:07: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 TAA11220 for ; Mon, 14 Jun 2004 19:07:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba0Y0-0004C7-Fq for simple@ietf.org; Mon, 14 Jun 2004 19:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba0X8-0003v4-00 for simple@ietf.org; Mon, 14 Jun 2004 19:06:30 -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 1Ba0WW-0003bC-00 for simple@ietf.org; Mon, 14 Jun 2004 19:05:52 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 14 Jun 2004 16:07:29 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5EN5GIn013240; Mon, 14 Jun 2004 16:05:17 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJK19049; Mon, 14 Jun 2004 19:04:11 -0400 (EDT) Message-ID: <40CE2EEB.1050606@cisco.com> Date: Mon, 14 Jun 2004 19:04:11 -0400 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: alex.audu@alcatel.com Subject: Re: [Simple] Re: MSRP: Max message size indication References: <40C77904.5020003@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" , cboulton@ubiquity.com, Ben Campbell X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Audu wrote: > I think there is great value in end-point being able to signal the > maximum size of data it is > willing /able to accept at a time. This information could be used by the > sender to, for example > send a less memory intensive version of say an image, instead of a full > blown memory hungry > version. This will allow the information to be communicated with a > decreased risk of truncation > at first try. That makes for a more efficient communication (than > without this feature). This is the most compelling argument for this feature that I have seen. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 21:58:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20974 for ; Mon, 14 Jun 2004 21:58:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba3Dq-00024R-FB for simple-archive@ietf.org; Mon, 14 Jun 2004 21:58:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba36c-0000fY-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 21:51:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba31R-0007JN-00; Mon, 14 Jun 2004 21:45:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba2IV-0000n0-46; Mon, 14 Jun 2004 20:59:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba1ij-0002VC-EC for simple@megatron.ietf.org; Mon, 14 Jun 2004 20:22:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15180 for ; Mon, 14 Jun 2004 20:22:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba1ih-0004bn-QR for simple@ietf.org; Mon, 14 Jun 2004 20:22:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba1hu-0004K9-00 for simple@ietf.org; Mon, 14 Jun 2004 20:21:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ba1hC-00041d-00 for simple@ietf.org; Mon, 14 Jun 2004 20:20:58 -0400 Received: from panther.cs.columbia.edu (IDENT:w9h4O408kjMg6kePWItg4O6zqyPltU/t@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5F0K5fq020611 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Jun 2004 20:20:05 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5F0K3Hs014072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jun 2004 20:20:04 -0400 Message-ID: <40CE40AE.2090009@cs.columbia.edu> Date: Mon, 14 Jun 2004 20:19:58 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40CE297C.7050702@cisco.com> In-Reply-To: <40CE297C.7050702@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.11.103533 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > If we introduce explicit device ids, then we end up with the following > possible situations: > > 1) a tuple, and the contact address it contains, is 1:1 with a device > > 2) several tuples, with distinct contact addresses, are associated with > the same device > > 3) a tuple, and the contact address it contains, is associated with > several devices > > 4) several tuples contain the same contact address > > 5) a tuple has no contact address > > 6) a tuple is associated with no device > > Of those, 4-6 present issues I don't want to talk about right now. I'm > only going to discuss 1-3. > > Case (1) is pretty easy to understand. You can consider the address to > represent either a service or a device. > > In case (2) you know some additional information, but it isn't clear to > me how valuable that information is. You would like to draw inferences, > but most of them aren't safe. Physical location is probably safe by any > reasonable definition of device. But that is easily dealt with by > replicating location information. Agreed; that's why I suggested that if we really need to save the cost of replicating information (a dubious saving in my mind, as a mechanical compression algorithm like LZW will do this without the conceptual hassles), that we should have explicit references to information blocks that are shared between tuples, rather than jumping from some rough notion of device to conclusions as to what's common and what's not. > > Simultaneous availability is I think what people would like to infer. > But that isn't always a good assumption. The nature of the device may > prevent me from using both capabilities simultaneously. At best, I think > device might be useful here in the PUBLISHed tuples so it could be used > by aggregation rules that also know the nature of the device and can > make the appropriate inferences. For instance the rules might decide to > replicate location information from a tuple that had it to tuples for > the same device that don't have it, and give precedence in some way when > multiple tuples provide location for the same device. But device info in > the resulting tuples that are delivered to subscribers would be much > less interesting and perhaps should be suppressed. Again, a 'location-id' identifier would seem more appropriate, which would explicitly indicate such replication. I'd rather not have to custom-program a PA, over which I'm unlikely to have any operational or programming control in many common settings. The whole point of our overall design should be, I think, that users can do likely and common tuple operations (filtering, suppression, modification, merging, inheritance) without custom per-user programming. > > Case (3) is just Brian's original approach, restated. I had problems > with it then, and I have problems with it now. It just isn't very clear > what this means operationally. Does it mean that the capabilities > described by the tuple are partitioned among the devices, or replicated > on each of the devices? Are requests presented to the address serviced > by one device, or by a combination of the devices? Without knowing the > answers to these questions, this kind of presence status is pretty > useless. And even if the questions are answered, only some answers lead > to useful results. I always thought that this was basically for the case where a server related to the presentity made the decision where to route messages and it was none of the watcher's business to guess or care as to whether a request to the URL (presumably directed to a proxy server for a SIP URL) would be parallel-forked to a bunch of my devices or whether the SIP URL refers to a B2BUA that magically assembles a bunch of boxes of plastic into a single logical service using 3pcc. I see no need to prohibit or describe this further. If the underlying devices are currently all carried by one user or vehicle, they might even have location information associated with them. If they are powered from the same car battery, they might even have the same power information, etc. > > In particular, if the capabilities are partitioned among the devices, > and requests are serviced by only a single device then the presence is > pretty much useless. > > If the capabilities are partitioned but all the devices may participate > in servicing a request, then its useful but the device information > itself is useless. > > The the capabilities are replicated on all devices and a single device > services a request, again I have useful presence information but knowing > the device info isn't helpful. Agreed. The whole point of this view, in my mind, is to hide, for whatever reason, the implementation of the service from the watcher. > > And I just can't make any sense of the situation where capabilities are > replicated and requests are serviced by a combination of devices. > > So the bottom line is that I can't find any situation in which case (3) > is useful. > > So, I guess I can support including device id in PUBLISH, for use in > aggregation, with restriction that there is at most one device id per > tuple. I would much prefer deciding where this is truly useful and necesary, beyond saving replicating location information across tuples. What exactly would the watcher do differently if it has this information? What additional important services are enabled? > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 23:23:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01299 for ; Mon, 14 Jun 2004 23:23:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4YI-0007A4-EM for simple-archive@ietf.org; Mon, 14 Jun 2004 23:23:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba4PQ-00055f-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 23:14:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba45I-0001go-00; Mon, 14 Jun 2004 22:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba3Om-0000vp-2a; Mon, 14 Jun 2004 22:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba2ix-00032r-JZ for simple@megatron.ietf.org; Mon, 14 Jun 2004 21:26: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 VAA18919 for ; Mon, 14 Jun 2004 21:26:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba2iv-0001XY-Sp for simple@ietf.org; Mon, 14 Jun 2004 21:26:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba2hv-0001Dl-00 for simple@ietf.org; Mon, 14 Jun 2004 21:25:48 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ba2hD-0000uD-00 for simple@ietf.org; Mon, 14 Jun 2004 21:25:03 -0400 Received: from panther.cs.columbia.edu (IDENT:EGUtzFDJdnGBQoskWWJs5jl26gb3oJkT@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5F1Okfq006260 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Jun 2004 21:24:46 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5F1OjHs020565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jun 2004 21:24:45 -0400 Message-ID: <40CE4FD3.60509@cs.columbia.edu> Date: Mon, 14 Jun 2004 21:24:35 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Ben Campbell References: <40AE51B6.2080608@dynamicsoft.com> In-Reply-To: <40AE51B6.2080608@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.14.103686 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , vkg@lucent.com, Jonathan Rosenberg , Simple WG Subject: [Simple] Re: RPID/CIPID comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > 1) A philisophical question about rpid: It is designed from the > perspective of the presentity exposing a lot of information about its > activity, mood, environment, etc. and letting the watcher make a > decision whether to communicate. What if, instead, I want to give very > little information beyond "Only call me if it is important", or some > other permutation. That is, if I don't care to tell the watcher details > about why. > > I don't mean this as a complaint about rpid per se; it is perfectly > valid for someone to wish to expose activity, etc. It may be enough to > just use a note element for this sort of thing. Or maybe it is a sphere > element extension. I think this has been covered in the meantime (addressed by the callee caps priority element). > > 2) In the security consideration section of the cipid draft: Do we want > to concern ourselves about the potential of inappropriate content in > icon or sound elements? (I suppose that this is not very different than > the potential for inappropriate IMs,etc.) I would agree that these are indeed roughly the same. One might restrict the size of images that a presentity can render, thus at least limiting the potential embarrassment if a non-PG-rated image is used as an icon. Unlike IMs, these icons and other representations are presumably only shown for vetted presentities that I have chosen to subscribe to. > Also, do we care about the > possibility of sounds and icons, or any of the external reference sort > of elements, to be used as covert information channels? Covert in what sense? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 23:24:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01528 for ; Mon, 14 Jun 2004 23:24:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4ZG-0007KZ-4y for simple-archive@ietf.org; Mon, 14 Jun 2004 23:24:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba4RO-0005fY-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 23:16:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba494-0002dC-00; Mon, 14 Jun 2004 22:57:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba3TT-0001V2-Vy; Mon, 14 Jun 2004 22:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba2oS-0004AP-16 for simple@megatron.ietf.org; Mon, 14 Jun 2004 21:32: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 VAA19339 for ; Mon, 14 Jun 2004 21:32:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba2oQ-0003TB-93 for simple@ietf.org; Mon, 14 Jun 2004 21:32:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba2nP-00039D-00 for simple@ietf.org; Mon, 14 Jun 2004 21:31:28 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba2mM-0002Tx-00 for simple@ietf.org; Mon, 14 Jun 2004 21:30:22 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5F1TSLp026491; Mon, 14 Jun 2004 20:29:28 -0500 Message-ID: <40CE50F1.5030206@dynamicsoft.com> Date: Mon, 14 Jun 2004 20:29:21 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne References: <40AE51B6.2080608@dynamicsoft.com> <40CE4FD3.60509@cs.columbia.edu> In-Reply-To: <40CE4FD3.60509@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , vkg@lucent.com, Jonathan Rosenberg , Simple WG Subject: [Simple] Re: RPID/CIPID comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> 1) A philisophical question about rpid: It is designed from the >> perspective of the presentity exposing a lot of information about its >> activity, mood, environment, etc. and letting the watcher make a >> decision whether to communicate. What if, instead, I want to give very >> little information beyond "Only call me if it is important", or some >> other permutation. That is, if I don't care to tell the watcher >> details about why. >> >> I don't mean this as a complaint about rpid per se; it is perfectly >> valid for someone to wish to expose activity, etc. It may be enough to >> just use a note element for this sort of thing. Or maybe it is a >> sphere element extension. > > > I think this has been covered in the meantime (addressed by the callee > caps priority element). Agreed. > >> >> 2) In the security consideration section of the cipid draft: Do we >> want to concern ourselves about the potential of inappropriate content >> in icon or sound elements? (I suppose that this is not very different >> than the potential for inappropriate IMs,etc.) > > > I would agree that these are indeed roughly the same. One might restrict > the size of images that a presentity can render, thus at least limiting > the potential embarrassment if a non-PG-rated image is used as an icon. > > Unlike IMs, these icons and other representations are presumably only > shown for vetted presentities that I have chosen to subscribe to. > Aggreed. >> Also, do we care about the possibility of sounds and icons, or any of >> the external reference sort of elements, to be used as covert >> information channels? > > > Covert in what sense? Example: I am a stock broker. My IMs are tightly monitored for FTC compliance. But my sounds/icons may not be. So I put in a a link sound that says "Buy Acme now!!!" when my friends subscribe. I realize that we do not generally worry about this in other arenas, so I am happy to ignore it here, too. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 14 23:28:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02332 for ; Mon, 14 Jun 2004 23:28:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4cv-0000e0-3e for simple-archive@ietf.org; Mon, 14 Jun 2004 23:28:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba4a3-0007iR-00 for simple-archive@ietf.org; Mon, 14 Jun 2004 23:25:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba4Sq-0005nX-00; Mon, 14 Jun 2004 23:18:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4Ab-0001rC-Cn; Mon, 14 Jun 2004 22:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba3gn-00037O-70 for simple@megatron.ietf.org; Mon, 14 Jun 2004 22:28: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 WAA22622 for ; Mon, 14 Jun 2004 22:28:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba3gl-0006Lf-Ah for simple@ietf.org; Mon, 14 Jun 2004 22:28:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba3MJ-0003Qy-00 for simple@ietf.org; Mon, 14 Jun 2004 22:07:31 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ba3CI-0001my-00 for simple@ietf.org; Mon, 14 Jun 2004 21:57:10 -0400 Received: from panther.cs.columbia.edu (IDENT:f12+PWfHXRhBySOclWDWQQiXDkG9ZgIf@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5F1v2fq014650 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Jun 2004 21:57:02 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5F1v1Hs023674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jun 2004 21:57:02 -0400 Message-ID: <40CE576A.9070805@cs.columbia.edu> Date: Mon, 14 Jun 2004 21:56:58 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Ben Campbell References: <40AE51B6.2080608@dynamicsoft.com> <40CE4FD3.60509@cs.columbia.edu> <40CE50F1.5030206@dynamicsoft.com> In-Reply-To: <40CE50F1.5030206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.14.103686 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , vkg@lucent.com, Jonathan Rosenberg , Simple WG Subject: [Simple] Re: RPID/CIPID comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Example: I am a stock broker. My IMs are tightly monitored for FTC > compliance. But my sounds/icons may not be. So I put in a a link sound > that says "Buy Acme now!!!" when my friends subscribe. > > I realize that we do not generally worry about this in other arenas, so > I am happy to ignore it here, too. I suspect that the right thing for the bank is to simply disallow the URL or only allow URLs that point to its own resources. Covert channels are hard to close; the broker could arrange that he would use "It will rain on the weekend" to signal that it's time to sell. Or you could use the refusal of subscriptions (refuse three times, then allow). I'll make a note of the issue, mostly because it's kind of interesting. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 15 00:10:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04393 for ; Tue, 15 Jun 2004 00:10:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba5HW-0005lj-5X for simple-archive@ietf.org; Tue, 15 Jun 2004 00:10:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba5Do-0004kH-00 for simple-archive@ietf.org; Tue, 15 Jun 2004 00:06:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Ba5C9-0004EB-00; Tue, 15 Jun 2004 00:05:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4qr-0002Zz-Jv; Mon, 14 Jun 2004 23:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4QA-0005a1-Fq for simple@megatron.ietf.org; Mon, 14 Jun 2004 23:15: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 XAA28429 for ; Mon, 14 Jun 2004 23:15:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4Q8-0005DV-9E for simple@ietf.org; Mon, 14 Jun 2004 23:15:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba46L-0001zI-00 for simple@ietf.org; Mon, 14 Jun 2004 22:55:06 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ba3dg-000616-00 for simple@ietf.org; Mon, 14 Jun 2004 22:25:28 -0400 Received: from panther.cs.columbia.edu (IDENT:DGOeJex7SkMXRY7d1Ci57x6Kjt+7WvpW@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5F2PMfq022422 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Jun 2004 22:25:22 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5F2PLHs026329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jun 2004 22:25:21 -0400 Message-ID: <40CE5E11.5010200@cs.columbia.edu> Date: Mon, 14 Jun 2004 22:25:21 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] RPID comments References: <40AB8ACF.1060601@nokia.com> In-Reply-To: <40AB8ACF.1060601@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.14.103686 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks for your comments; I think I have folded them all into the documents, as commented below. Aki Niemi wrote: > Hi, > > Reviewed RPID at -04 and here are my findings. There were a couple of > - Nit: the hanging lists become hard to read with no empty lines between > entries. Hoever, I see this may be an xml2rfc bug, so I guess I'll take > it elsewhere. Indeed; not my doing. > > - In activities, while all elements may be used either with OPEN or > CLOSED status depending on the presentity's intent, this intent isn't > described very well, except for "busy". For some activities such as > "away" there seems to be a similar typical intent, which might be good > to add. I added the same caveat for "away". There are clearly other activities where CLOSED is the likely activity. (Why would I set activity to 'vacation' and still be OPEN?) However, since there are always weird "what-if" cases where OPEN is plausible, I don't see much point in trying to proscribe this. After all, the meaning of activity and reachability is largely orthogonal, except for the two 'away' variations. > - In 4.4, why distinguish between different tuple types when defining > the element? I don't understand the second paragraph: What does > it mean when the "determines the idle time for the whole tuple"? > is always scoped to a single tuple irrespective of the tuple > type, no? Removed, as I've also gotten rid of the whole element. > > - 4.5, should probably say something about the extensibility of the mood > element? That in addition to the enumerated values, more can be added > later (either freetext or registered). Later discussion seems to indicate that the list is probably best seen as suggestions rather than an enumeration. There seems little practical value in having an IANA mood registry. > > - 4.10, come to think of it now, it seems that the CIPID should > actually be an RPID element just like the status-icon is. Is there a > difference other than that is a sibling of or > whereas is of ? I agree that this can be in either, but I suspect once you move the , pretty much all the other CIPID elements can conceivably move as well, defeating the purpose of the split. I'd rather leave this alone. > > 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-bounces@ietf.org Tue Jun 15 00:20:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05649 for ; Tue, 15 Jun 2004 00:20:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba5R9-0001Nb-86 for simple-archive@ietf.org; Tue, 15 Jun 2004 00:20:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba5QF-000155-00 for simple-archive@ietf.org; Tue, 15 Jun 2004 00:19:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba5PV-0000mz-00; Tue, 15 Jun 2004 00:18:57 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ba5PW-00071a-SU; Tue, 15 Jun 2004 00:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4t0-0003e5-2d; Mon, 14 Jun 2004 23:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4XK-00074E-2X for simple@megatron.ietf.org; Mon, 14 Jun 2004 23:22:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01109 for ; Mon, 14 Jun 2004 23:22:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4XI-0006kf-60 for simple@ietf.org; Mon, 14 Jun 2004 23:22:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba4NB-0004Ui-00 for simple@ietf.org; Mon, 14 Jun 2004 23:12:30 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ba40z-00019q-00 for simple@ietf.org; Mon, 14 Jun 2004 22:49:33 -0400 Received: from panther.cs.columbia.edu (IDENT:DX0Mr0hNnNlwCBJ5+lDm/n4+om5nH1Q4@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5F2nWfq028753 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Jun 2004 22:49:32 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-165-64.mad.east.verizon.net [141.153.165.64]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5F2nUHs028819 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jun 2004 22:49:32 -0400 Message-ID: <40CE63BE.9020000@cs.columbia.edu> Date: Mon, 14 Jun 2004 22:49:34 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] RPID: an element representing the presentity vs. the tuple References: <40AB8C44.5000606@nokia.com> In-Reply-To: <40AB8C44.5000606@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.101390, Antispam-Data: 2004.6.14.103686 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I suspect the outcome of the current iteration #97 of "what is a tuple" discussion will resolve this issue. In order to make forward progress, I'd like to suggest that we adopt the approach indicated in both CIPID and RPID. It seems to do the trick with minimal complexity. Please register objections (or agreement) soon. Henning Aki Niemi wrote: > Hi, > > To me at least, there seems to be a discrepancy between the models used > in CIPID and RPID wrt an element representing the presentity vs. a tuple. > > In CIPID, elements that describe the presentity are under > and elements that describe the tuples are under . In RPID, many > of the elements might well represent either one (although some like > typically would represent the presentity), but the only way to > indicate that is to set the to "presentity". > > I think I'm leaning towards the CIPID way of indicating this, i.e., > putting those elements that describe the presentity directly under > , and others either under or . > > At least and should be like this, perhaps also > , and . > > 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-bounces@ietf.org Tue Jun 15 09:20:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16483 for ; Tue, 15 Jun 2004 09:20:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaDs3-0004rv-OL for simple-archive@ietf.org; Tue, 15 Jun 2004 09:20:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaDr4-0004XU-00 for simple-archive@ietf.org; Tue, 15 Jun 2004 09:19:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BaDpx-0003tS-00; Tue, 15 Jun 2004 09:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaDl7-0006gS-NG; Tue, 15 Jun 2004 09:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaDZI-00052B-BU for simple@megatron.ietf.org; Tue, 15 Jun 2004 09:01: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 JAA15496 for ; Tue, 15 Jun 2004 09:01:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaDZH-00064C-LO for simple@ietf.org; Tue, 15 Jun 2004 09:01:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaDWg-0005Ex-00 for simple@ietf.org; Tue, 15 Jun 2004 08:58:55 -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 1BaDUT-0004PX-00 for simple@ietf.org; Tue, 15 Jun 2004 08:56:37 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2004 05:58:15 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5FCtsIn028506; Tue, 15 Jun 2004 05:55:55 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJK49476; Tue, 15 Jun 2004 08:55:54 -0400 (EDT) Message-ID: <40CEF1D9.1090404@cisco.com> Date: Tue, 15 Jun 2004 08:55:53 -0400 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: Henning Schulzrinne Subject: Re: [Simple] RPID comments References: <40AB8ACF.1060601@nokia.com> <40CE5E11.5010200@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Later discussion seems to indicate that the list is probably best seen > as suggestions rather than an enumeration. There seems little practical > value in having an IANA mood registry. Yes, moods can be very personal. For instance, that broker may well be in the mood "Buy Acme"! Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 16 12:55:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20179 for ; Wed, 16 Jun 2004 12:55:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Badh6-0000cA-Lf for simple-archive@ietf.org; Wed, 16 Jun 2004 12:55:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BadM2-0004qu-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 12:33:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bad1E-0001JE-01; Wed, 16 Jun 2004 12:12:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BacwI-00085b-O8; Wed, 16 Jun 2004 12:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacUj-0008Jd-E9; Wed, 16 Jun 2004 11:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacHy-0003ES-Mr for simple@megatron.ietf.org; Wed, 16 Jun 2004 11:25: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 LAA07812 for ; Wed, 16 Jun 2004 11:25:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacHu-0001F0-Sy for simple@ietf.org; Wed, 16 Jun 2004 11:25:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BabVM-0001La-00 for simple@ietf.org; Wed, 16 Jun 2004 10:35:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaagX-0001Ex-00 for simple@ietf.org; Wed, 16 Jun 2004 09:42:37 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Baa8W-0006MU-A2 for simple@ietf.org; Wed, 16 Jun 2004 09:07:28 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5GD7F205719; Wed, 16 Jun 2004 16:07:15 +0300 (EET DST) X-Scanned: Wed, 16 Jun 2004 16:07:01 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5GD71Hv024380; Wed, 16 Jun 2004 16:07:01 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00nb8sdN; Wed, 16 Jun 2004 16:06:59 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5GD6xH29849; Wed, 16 Jun 2004 16:06:59 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Jun 2004 16:06:59 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.42.188 172.21.42.188 via HTTP with MS-WebStorage 6.0.6249 Received: from esdhcp09nok08188.ntc.nokia.com by esebe013.ntc.nokia.com; 16 Jun 2004 16:06:58 +0300 Subject: Re: [Simple] RPID: what does tuple-type really mean? From: Aki Niemi To: ext Henning Schulzrinne In-Reply-To: <40CCFC5A.1040603@cs.columbia.edu> References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40C960DF.8070702@nokia.com> <40CCFC5A.1040603@cs.columbia.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1087391217.25275.48.camel@esdhcp09nok08188.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 16:06:58 +0300 X-OriginalArrivalTime: 16 Jun 2004 13:06:59.0101 (UTC) FILETIME=[CEB544D0:01C453A2] Content-Transfer-Encoding: 7bit Cc: ext Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Mon, 2004-06-14 at 04:16, ext Henning Schulzrinne wrote: ...snip... > > Out of these three, 1) seems the cleanest, because it plays well with > > other specifications like presence authorization and partial > > notifications. The others would require changes elsewhere were we to > > adopt either one of them. > > (2) still has the problem that per-tuple override isn't particularly > clean, syntactically. Only (3) clearly indicates an inheritance > relationship, i.e., a tuple could override the generic RPID information > if it has contradictory information. I don't think the inheritance relationship itself is particularly clear. In fact most (if not all) RPID/CIPID elements are interpreted within a different context depending on whether they are pertaining to the presentity or the tuple (granted some of them only make sense in either one). So I'd rather define explicitly how overrides should occur, case-by-case when there is an explicit inheritance relationship to a given element. And in that sense, it doesn't seem to matter whether the element is under or under a new element. Cheers, Aki > Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 16 13:17:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22264 for ; Wed, 16 Jun 2004 13:17:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bae20-000467-6u for simple-archive@ietf.org; Wed, 16 Jun 2004 13:17:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bade8-00004X-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 12:52:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BadI8-00043b-00; Wed, 16 Jun 2004 12:29:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bad60-0001U5-O8; Wed, 16 Jun 2004 12:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacWZ-000163-3n; Wed, 16 Jun 2004 11:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacNJ-0004nC-VO for simple@megatron.ietf.org; Wed, 16 Jun 2004 11:30: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 LAA09340 for ; Wed, 16 Jun 2004 11:30:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacNG-0002DE-5L for simple@ietf.org; Wed, 16 Jun 2004 11:30:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Babd6-0002V8-00 for simple@ietf.org; Wed, 16 Jun 2004 10:43:09 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Baahc-0001gO-00 for simple@ietf.org; Wed, 16 Jun 2004 09:43:45 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5GDHpN13388; Wed, 16 Jun 2004 16:17:52 +0300 (EET DST) X-Scanned: Wed, 16 Jun 2004 16:17:34 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5GDHY3E014320; Wed, 16 Jun 2004 16:17:34 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Awpbeh; Wed, 16 Jun 2004 16:16:08 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5GDG7H06956; Wed, 16 Jun 2004 16:16:08 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Jun 2004 16:14:17 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Jun 2004 16:14:17 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.42.188 172.21.42.188 via HTTP with MS-WebStorage 6.0.6249 Received: from esdhcp09nok08188.ntc.nokia.com by esebe013.ntc.nokia.com; 16 Jun 2004 16:14:15 +0300 Subject: Re: [Simple] RPID: what does tuple-type really mean? From: Aki Niemi To: ext Jonathan Rosenberg In-Reply-To: <40C970FE.2080106@dynamicsoft.com> References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40C960DF.8070702@nokia.com> <40C970FE.2080106@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1087391655.25275.57.camel@esdhcp09nok08188.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 16:14:15 +0300 X-OriginalArrivalTime: 16 Jun 2004 13:14:17.0276 (UTC) FILETIME=[D3E177C0:01C453A3] Content-Transfer-Encoding: 7bit Cc: Mikko =?ISO-8859-1?Q?L=F6nnfors?= , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Fri, 2004-06-11 at 11:44, ext Jonathan Rosenberg wrote: ...snip... > I think we are going to need to make sure that the authorization stuff > is aligned with the PIDF/RPID data models no matter what we do. Part of > my difficulties in wrapping up the authorization spec is that we keep > tripping on the "what is a tuple" issue in figuring out what kind of > functions to include in the authorization policies. This is true. So from this point of view, it would be good not to let PIDF restrict us in making things explicit. > You raise a good point on partial notifications. Using a separate > element also won't play well with that. I'd hate to force > things into tuples when they don't belong, just because partial > notifications doesnt know about anything but tuples. I agree. Mikko, what do you think about this? Cheers, Aki > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 16 18:13:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23052 for ; Wed, 16 Jun 2004 18:13:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Baieb-0001ai-Uu for simple-archive@ietf.org; Wed, 16 Jun 2004 18:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaibI-0000VO-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 18:09:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaiX0-0007BF-00; Wed, 16 Jun 2004 18:05:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaiX4-0000wP-01; Wed, 16 Jun 2004 18:05:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BahiV-0008Ct-TR; Wed, 16 Jun 2004 17:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BagR8-0001Ok-UZ for simple@megatron.ietf.org; Wed, 16 Jun 2004 15: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 PAA10417 for ; Wed, 16 Jun 2004 15:51:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BagR4-0001mI-Tg for simple@ietf.org; Wed, 16 Jun 2004 15:51:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BagEq-0007RK-00 for simple@ietf.org; Wed, 16 Jun 2004 15:38:25 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BafuK-0003K7-00 for simple@ietf.org; Wed, 16 Jun 2004 15:17:12 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5GJGjLp002917 for ; Wed, 16 Jun 2004 14:16:45 -0500 Message-ID: <40D09C94.6030207@dynamicsoft.com> Date: Wed, 16 Jun 2004 14:16:36 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) 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] MSRP: delivery reports and transaction responses X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit In Boston, we had a proposal for a comprimise solution on handling delivery reports and transaction responses. The primary contributors have had a number of discussions, and came up with some details. This does not address questions of DSN format, nor does it talk about DSN reports that occur after a session has ended--those will be shortly forthcoming. This note only addresses when to send DSN reports and transaction responses, and the relationship between them. ----------------------- First, a clarification of terms. When we use the term "delivery report" (or "reports" for short), we mean a report sent back to the sender to tell it the delivery status. This is different than "transaction responses" (or "responses" for short). Transaction responses to SEND requests are strictly hop-by-hop, while delivery reports are generally end-to-end, or middle-to-end if the reporting device is a relay. The sender requests delivery reports on a message by message basis. This is done in an MSRP header in a SEND request. That header has two distinct flags. One indicates the desire to get failure reports, and the other indicates the desire to get success reports. The sender can set any combination of these flags. The success report request flag can have values of true or false. If the flag is true, then the receiving endpoint MUST send back a success report when it successfully receives a message. This does not say anything about the message disposition after reception, only that is was successfully received. If this flag is false, the receiving endpoint MUST NOT send success reports. Success reports are strictly end-to-end, that is, Relays _never_ send success reports. The failure report request flag can have three values: True, False, and "partial". If this flag is false, then both the receiving endpoint and any relays MUST NOT send failure reports. If it is "partial", then the receiving device and any relay SHOULD send an error report if it detects a "fatal" error; that is, an error which prevents delivery of the message. Now, here is the tricky part: None of the conditions described so far involve the use of transaction responses to SEND requests. If the failure report request flag is any value other than True, then MSRP devices SHOULD NOT send transaction responses for the request. Furthermore, devices MUST NOT "expect" transaction responses, although they should not freak out if they get one. If the failure report request flag is True, then the recipient, and any relays, MUST send send a transaction response. If any device detects an error which prevents delivery, it SHOULD send a failure transaction response back to the previous hop. If it is unable to immediately detect the error, it MAY send a 200 OK response, followed by a failure _report_ when the error is detected. (This is mainly for gateway devices, which may not notice the error until they are informed by the downstream network.) If any relay receives a failure transaction response to a SEND request where failure reports are requested, that device MUST send a failure report. If the sending device receives a failure transaction response, it acts the same as if it had received a failure report with the same information. Furthermore, if any such device determines that delivery to the next hop has failed because either a transport error or a locally defined timeout period has expired before receiving a 200 OK response, it MUST act as if it had received an appropriate error response. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 16 19:18:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29667 for ; Wed, 16 Jun 2004 19:18:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bajfi-0001kg-By for simple-archive@ietf.org; Wed, 16 Jun 2004 19:18:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BajeX-0001K5-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 19:17:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bajdh-0000aP-00; Wed, 16 Jun 2004 19:16:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BajR5-0004pA-JL; Wed, 16 Jun 2004 19:03:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BajEB-0007IY-Gv for simple@megatron.ietf.org; Wed, 16 Jun 2004 18:49: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 SAA27401 for ; Wed, 16 Jun 2004 18:49:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BajE7-000728-Cn for simple@ietf.org; Wed, 16 Jun 2004 18:49:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BajD8-0006fn-00 for simple@ietf.org; Wed, 16 Jun 2004 18:48:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BajC7-0005za-00 for simple@ietf.org; Wed, 16 Jun 2004 18:47:47 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2004 18:47:32 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5GMlHTJ009052; Wed, 16 Jun 2004 18:47:19 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id AZZ71689; Wed, 16 Jun 2004 15:47:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jun 2004 18:48:07 -0400 To: Ben Campbell , Simple WG From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D09C94.6030207@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Ben, It seems like you could simplify things further if you de-coupled the reports from the responses described in your last 4 paragraphs. This would also help support the clarity you seek in the first paragraph and enable some symmetry in having only binary flags. (Having a 'tricky' part is the first clue to complexity.) It would also help if you define the behavior upon receiving the SEND with each flag for each device type (senders, endpoints, relays, gateways, recipients -- a non-redundant set would help readability). Lumping two flags or device types in one sentence makes parsing more difficult. Mike At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >In Boston, we had a proposal for a comprimise solution on handling >delivery reports and transaction responses. The primary contributors have >had a number of discussions, and came up with some details. This does not >address questions of DSN format, nor does it talk about DSN reports that >occur after a session has ended--those will be shortly forthcoming. This >note only addresses when to send DSN reports and transaction responses, >and the relationship between them. > >----------------------- > >First, a clarification of terms. When we use the term "delivery report" >(or "reports" for short), we mean a report sent back to the sender to tell >it the delivery status. This is different than "transaction responses" (or >"responses" for short). Transaction responses to SEND requests are >strictly hop-by-hop, while delivery reports are generally end-to-end, or >middle-to-end if the reporting device is a relay. > >The sender requests delivery reports on a message by message basis. This >is done in an MSRP header in a SEND request. That header has two distinct >flags. One indicates the desire to get failure reports, and the other >indicates the desire to get success reports. The sender can set any >combination of these flags. > >The success report request flag can have values of true or false. If the >flag is true, then the receiving endpoint MUST send back a success report >when it successfully receives a message. This does not say anything about >the message disposition after reception, only that is was successfully >received. If this flag is false, the receiving endpoint MUST NOT send >success reports. Success reports are strictly end-to-end, that is, Relays >_never_ send success reports. > >The failure report request flag can have three values: True, False, and >"partial". If this flag is false, then both the receiving endpoint and any >relays MUST NOT send failure reports. If it is "partial", then the >receiving device and any relay SHOULD send an error report if it detects a >"fatal" error; that is, an error which prevents delivery of the message. > >Now, here is the tricky part: None of the conditions described so far >involve the use of transaction responses to SEND requests. If the failure >report request flag is any value other than True, then MSRP devices SHOULD >NOT send transaction responses for the request. Furthermore, devices MUST >NOT "expect" transaction responses, although they should not freak out if >they get one. > >If the failure report request flag is True, then the recipient, and any >relays, MUST send send a transaction response. If any device detects an >error which prevents delivery, it SHOULD send a failure transaction >response back to the previous hop. If it is unable to immediately detect >the error, it MAY send a 200 OK response, followed by a failure _report_ >when the error is detected. (This is mainly for gateway devices, which may >not notice the error until they are informed by the downstream network.) > >If any relay receives a failure transaction response to a SEND request >where failure reports are requested, that device MUST send a failure >report. If the sending device receives a failure transaction response, it >acts the same as if it had received a failure report with the same >information. Furthermore, if any such device determines that delivery to >the next hop has failed because either a transport error or a locally >defined timeout period has expired before receiving a 200 OK response, it >MUST act as if it had received an appropriate error response. > >_______________________________________________ >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-bounces@ietf.org Wed Jun 16 19:20:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29745 for ; Wed, 16 Jun 2004 19:20:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bajhi-0002Z7-BG for simple-archive@ietf.org; Wed, 16 Jun 2004 19:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bajfn-0001lF-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 19:18:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bajej-0001HZ-00; Wed, 16 Jun 2004 19:17:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BajSY-00058J-MJ; Wed, 16 Jun 2004 19:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BajK4-0001fd-3X for simple@megatron.ietf.org; Wed, 16 Jun 2004 18:56: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 SAA27523 for ; Wed, 16 Jun 2004 18:55:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BajJz-00015K-R7 for simple@ietf.org; Wed, 16 Jun 2004 18:55:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BajIw-0000gA-00 for simple@ietf.org; Wed, 16 Jun 2004 18:54: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 1BajH9-0007Xq-00 for simple@ietf.org; Wed, 16 Jun 2004 18:52:59 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5GMpnLp003501; Wed, 16 Jun 2004 17:51:50 -0500 Message-ID: <40D0CEFC.6040504@dynamicsoft.com> Date: Wed, 16 Jun 2004 17:51:40 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit First, just to make sure things are clear, this was not proposed draft verbiage, it was just a quick descripiton of the approach. Not only will the draft language be more precise, we will be splitting the endpoint vs. relay behavior between the appropriate drafts. Further comments inline: Mike Hammer wrote: > Ben, > > It seems like you could simplify things further if you de-coupled the > reports from the responses described in your last 4 paragraphs. Do you mean decouple the behavior, or decouple the descriptions? If the first, please let me know what you have in mind. This > would also help support the clarity you seek in the first paragraph and > enable some symmetry in having only binary flags. (Having a 'tricky' > part is the first clue to complexity.) > > It would also help if you define the behavior upon receiving the SEND > with each flag for each device type (senders, endpoints, relays, > gateways, recipients -- a non-redundant set would help readability). > Lumping two flags or device types in one sentence makes parsing more > difficult. The drafts will do that. > > Mike > > > At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: > >> In Boston, we had a proposal for a comprimise solution on handling >> delivery reports and transaction responses. The primary contributors >> have had a number of discussions, and came up with some details. This >> does not address questions of DSN format, nor does it talk about DSN >> reports that occur after a session has ended--those will be shortly >> forthcoming. This note only addresses when to send DSN reports and >> transaction responses, and the relationship between them. >> >> ----------------------- >> >> First, a clarification of terms. When we use the term "delivery >> report" (or "reports" for short), we mean a report sent back to the >> sender to tell it the delivery status. This is different than >> "transaction responses" (or "responses" for short). Transaction >> responses to SEND requests are strictly hop-by-hop, while delivery >> reports are generally end-to-end, or middle-to-end if the reporting >> device is a relay. >> >> The sender requests delivery reports on a message by message basis. >> This is done in an MSRP header in a SEND request. That header has two >> distinct flags. One indicates the desire to get failure reports, and >> the other indicates the desire to get success reports. The sender can >> set any combination of these flags. >> >> The success report request flag can have values of true or false. If >> the flag is true, then the receiving endpoint MUST send back a success >> report when it successfully receives a message. This does not say >> anything about the message disposition after reception, only that is >> was successfully received. If this flag is false, the receiving >> endpoint MUST NOT send success reports. Success reports are strictly >> end-to-end, that is, Relays _never_ send success reports. >> >> The failure report request flag can have three values: True, False, >> and "partial". If this flag is false, then both the receiving endpoint >> and any relays MUST NOT send failure reports. If it is "partial", then >> the receiving device and any relay SHOULD send an error report if it >> detects a "fatal" error; that is, an error which prevents delivery of >> the message. >> >> Now, here is the tricky part: None of the conditions described so far >> involve the use of transaction responses to SEND requests. If the >> failure report request flag is any value other than True, then MSRP >> devices SHOULD NOT send transaction responses for the request. >> Furthermore, devices MUST NOT "expect" transaction responses, although >> they should not freak out if they get one. >> >> If the failure report request flag is True, then the recipient, and >> any relays, MUST send send a transaction response. If any device >> detects an error which prevents delivery, it SHOULD send a failure >> transaction response back to the previous hop. If it is unable to >> immediately detect the error, it MAY send a 200 OK response, followed >> by a failure _report_ when the error is detected. (This is mainly for >> gateway devices, which may not notice the error until they are >> informed by the downstream network.) >> >> If any relay receives a failure transaction response to a SEND request >> where failure reports are requested, that device MUST send a failure >> report. If the sending device receives a failure transaction response, >> it acts the same as if it had received a failure report with the same >> information. Furthermore, if any such device determines that delivery >> to the next hop has failed because either a transport error or a >> locally defined timeout period has expired before receiving a 200 OK >> response, it MUST act as if it had received an appropriate error >> response. >> >> _______________________________________________ >> 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-bounces@ietf.org Wed Jun 16 19:49:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02024 for ; Wed, 16 Jun 2004 19:49:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bak9L-0005zR-2Y for simple-archive@ietf.org; Wed, 16 Jun 2004 19:48:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bak8T-0005c0-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 19:48:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bak7v-0005D9-00; Wed, 16 Jun 2004 19:47:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bajsj-0005k7-FT; Wed, 16 Jun 2004 19:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bajhh-0002Ra-OK for simple@megatron.ietf.org; Wed, 16 Jun 2004 19:20: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 TAA29736 for ; Wed, 16 Jun 2004 19:20:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bajhd-0002Ux-HX for simple@ietf.org; Wed, 16 Jun 2004 19:20:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bajfb-0001jp-00 for simple@ietf.org; Wed, 16 Jun 2004 19:18:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BajeR-0000vT-00 for simple@ietf.org; Wed, 16 Jun 2004 19:17:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2004 19:16:47 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5GNGYc3018113; Wed, 16 Jun 2004 19:16:34 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id AZZ73439; Wed, 16 Jun 2004 16:16:33 -0700 (PDT) Message-Id: <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jun 2004 19:17:24 -0400 To: Ben Campbell From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D0CEFC.6040504@dynamicsoft.com> References: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 The use of the terms sender and recipient could be endpoints or relays, depending on whether you are talking hop-by-hop or end-to-end. So, I am a bit fuzzy until some more precise language is provided. Otherwise, I am guessing as to exactly what you intended. Your fist paragraph indicates that reports are endpoint only, and thus omits any discussion of relays. But, then the report failure flag includes relay behavior reactions. Thus, my uncertainty and guessing. However, either way, the overall behavior could be the same using three flags instead of two. The suggestions were to help confirm for myself that I had read your intent correctly. Mike At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: >First, just to make sure things are clear, this was not proposed draft >verbiage, it was just a quick descripiton of the approach. Not only will >the draft language be more precise, we will be splitting the endpoint vs. >relay behavior between the appropriate drafts. > >Further comments inline: > >Mike Hammer wrote: > >>Ben, >>It seems like you could simplify things further if you de-coupled the >>reports from the responses described in your last 4 paragraphs. > >Do you mean decouple the behavior, or decouple the descriptions? If the >first, please let me know what you have in mind. > >This >>would also help support the clarity you seek in the first paragraph and >>enable some symmetry in having only binary flags. (Having a 'tricky' >>part is the first clue to complexity.) >>It would also help if you define the behavior upon receiving the SEND >>with each flag for each device type (senders, endpoints, relays, >>gateways, recipients -- a non-redundant set would help readability). >>Lumping two flags or device types in one sentence makes parsing more >>difficult. > >The drafts will do that. > >>Mike >> >>At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >> >>>In Boston, we had a proposal for a comprimise solution on handling >>>delivery reports and transaction responses. The primary contributors >>>have had a number of discussions, and came up with some details. This >>>does not address questions of DSN format, nor does it talk about DSN >>>reports that occur after a session has ended--those will be shortly >>>forthcoming. This note only addresses when to send DSN reports and >>>transaction responses, and the relationship between them. >>> >>>----------------------- >>> >>>First, a clarification of terms. When we use the term "delivery report" >>>(or "reports" for short), we mean a report sent back to the sender to >>>tell it the delivery status. This is different than "transaction >>>responses" (or "responses" for short). Transaction responses to SEND >>>requests are strictly hop-by-hop, while delivery reports are generally >>>end-to-end, or middle-to-end if the reporting device is a relay. >>> >>>The sender requests delivery reports on a message by message basis. This >>>is done in an MSRP header in a SEND request. That header has two >>>distinct flags. One indicates the desire to get failure reports, and the >>>other indicates the desire to get success reports. The sender can set >>>any combination of these flags. >>> >>>The success report request flag can have values of true or false. If the >>>flag is true, then the receiving endpoint MUST send back a success >>>report when it successfully receives a message. This does not say >>>anything about the message disposition after reception, only that is was >>>successfully received. If this flag is false, the receiving endpoint >>>MUST NOT send success reports. Success reports are strictly end-to-end, >>>that is, Relays _never_ send success reports. >>> >>>The failure report request flag can have three values: True, False, and >>>"partial". If this flag is false, then both the receiving endpoint and >>>any relays MUST NOT send failure reports. If it is "partial", then the >>>receiving device and any relay SHOULD send an error report if it detects >>>a "fatal" error; that is, an error which prevents delivery of the message. >>> >>>Now, here is the tricky part: None of the conditions described so far >>>involve the use of transaction responses to SEND requests. If the >>>failure report request flag is any value other than True, then MSRP >>>devices SHOULD NOT send transaction responses for the request. >>>Furthermore, devices MUST NOT "expect" transaction responses, although >>>they should not freak out if they get one. >>> >>>If the failure report request flag is True, then the recipient, and any >>>relays, MUST send send a transaction response. If any device detects an >>>error which prevents delivery, it SHOULD send a failure transaction >>>response back to the previous hop. If it is unable to immediately detect >>>the error, it MAY send a 200 OK response, followed by a failure _report_ >>>when the error is detected. (This is mainly for gateway devices, which >>>may not notice the error until they are informed by the downstream network.) >>> >>>If any relay receives a failure transaction response to a SEND request >>>where failure reports are requested, that device MUST send a failure >>>report. If the sending device receives a failure transaction response, >>>it acts the same as if it had received a failure report with the same >>>information. Furthermore, if any such device determines that delivery to >>>the next hop has failed because either a transport error or a locally >>>defined timeout period has expired before receiving a 200 OK response, >>>it MUST act as if it had received an appropriate error response. >>> >>>_______________________________________________ >>>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-bounces@ietf.org Wed Jun 16 20:23:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03717 for ; Wed, 16 Jun 2004 20:23:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bakh8-0003Yz-11 for simple-archive@ietf.org; Wed, 16 Jun 2004 20:23:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BakgE-0003Cd-00 for simple-archive@ietf.org; Wed, 16 Jun 2004 20:22:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BakfP-0002TZ-00; Wed, 16 Jun 2004 20:22:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bakb4-0005xX-Sr; Wed, 16 Jun 2004 20:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BakWg-0004b6-0V for simple@megatron.ietf.org; Wed, 16 Jun 2004 20: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 UAA03271 for ; Wed, 16 Jun 2004 20:13:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BakWb-0007Ar-J6 for simple@ietf.org; Wed, 16 Jun 2004 20:13:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BakVb-0006nz-00 for simple@ietf.org; Wed, 16 Jun 2004 20:12:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BakVI-0006Rf-00 for simple@ietf.org; Wed, 16 Jun 2004 20:11:40 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2004 17:08:26 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5H06wwD028051; Wed, 16 Jun 2004 17:07:06 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJM04828; Wed, 16 Jun 2004 20:06:57 -0400 (EDT) Message-ID: <40D0E0A0.8040000@cisco.com> Date: Wed, 16 Jun 2004 20:06:56 -0400 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: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit When I read the proposal I had a similar reaction to what Mike had. I was going to comment but decided it was good enough so I would leave it be. But since Mike was troubled by the same thing I will support him: It would be clearer if there were three flags rather than two, with the the third explicitly controlling the sending of responses. This does permit some nonsense combinations, but they can be simply declared illegal. (And if anyone uses a nonsense combination they will get what they deserve.) And with three flags, they would all be binary. Paul Mike Hammer wrote: > The use of the terms sender and recipient could be endpoints or relays, > depending on whether you are talking hop-by-hop or end-to-end. So, I am > a bit fuzzy until some more precise language is provided. Otherwise, I > am guessing as to exactly what you intended. Your fist paragraph > indicates that reports are endpoint only, and thus omits any discussion > of relays. But, then the report failure flag includes relay behavior > reactions. Thus, my uncertainty and guessing. > > However, either way, the overall behavior could be the same using three > flags instead of two. The suggestions were to help confirm for myself > that I had read your intent correctly. > > Mike > > > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: > >> First, just to make sure things are clear, this was not proposed draft >> verbiage, it was just a quick descripiton of the approach. Not only >> will the draft language be more precise, we will be splitting the >> endpoint vs. relay behavior between the appropriate drafts. >> >> Further comments inline: >> >> Mike Hammer wrote: >> >>> Ben, >>> It seems like you could simplify things further if you de-coupled the >>> reports from the responses described in your last 4 paragraphs. >> >> >> Do you mean decouple the behavior, or decouple the descriptions? If >> the first, please let me know what you have in mind. >> >> This >> >>> would also help support the clarity you seek in the first paragraph >>> and enable some symmetry in having only binary flags. (Having a >>> 'tricky' part is the first clue to complexity.) >>> It would also help if you define the behavior upon receiving the SEND >>> with each flag for each device type (senders, endpoints, relays, >>> gateways, recipients -- a non-redundant set would help readability). >>> Lumping two flags or device types in one sentence makes parsing more >>> difficult. >> >> >> The drafts will do that. >> >>> Mike >>> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >>> >>>> In Boston, we had a proposal for a comprimise solution on handling >>>> delivery reports and transaction responses. The primary contributors >>>> have had a number of discussions, and came up with some details. >>>> This does not address questions of DSN format, nor does it talk >>>> about DSN reports that occur after a session has ended--those will >>>> be shortly forthcoming. This note only addresses when to send DSN >>>> reports and transaction responses, and the relationship between them. >>>> >>>> ----------------------- >>>> >>>> First, a clarification of terms. When we use the term "delivery >>>> report" (or "reports" for short), we mean a report sent back to the >>>> sender to tell it the delivery status. This is different than >>>> "transaction responses" (or "responses" for short). Transaction >>>> responses to SEND requests are strictly hop-by-hop, while delivery >>>> reports are generally end-to-end, or middle-to-end if the reporting >>>> device is a relay. >>>> >>>> The sender requests delivery reports on a message by message basis. >>>> This is done in an MSRP header in a SEND request. That header has >>>> two distinct flags. One indicates the desire to get failure reports, >>>> and the other indicates the desire to get success reports. The >>>> sender can set any combination of these flags. >>>> >>>> The success report request flag can have values of true or false. If >>>> the flag is true, then the receiving endpoint MUST send back a >>>> success report when it successfully receives a message. This does >>>> not say anything about the message disposition after reception, only >>>> that is was successfully received. If this flag is false, the >>>> receiving endpoint MUST NOT send success reports. Success reports >>>> are strictly end-to-end, that is, Relays _never_ send success reports. >>>> >>>> The failure report request flag can have three values: True, False, >>>> and "partial". If this flag is false, then both the receiving >>>> endpoint and any relays MUST NOT send failure reports. If it is >>>> "partial", then the receiving device and any relay SHOULD send an >>>> error report if it detects a "fatal" error; that is, an error which >>>> prevents delivery of the message. >>>> >>>> Now, here is the tricky part: None of the conditions described so >>>> far involve the use of transaction responses to SEND requests. If >>>> the failure report request flag is any value other than True, then >>>> MSRP devices SHOULD NOT send transaction responses for the request. >>>> Furthermore, devices MUST NOT "expect" transaction responses, >>>> although they should not freak out if they get one. >>>> >>>> If the failure report request flag is True, then the recipient, and >>>> any relays, MUST send send a transaction response. If any device >>>> detects an error which prevents delivery, it SHOULD send a failure >>>> transaction response back to the previous hop. If it is unable to >>>> immediately detect the error, it MAY send a 200 OK response, >>>> followed by a failure _report_ when the error is detected. (This is >>>> mainly for gateway devices, which may not notice the error until >>>> they are informed by the downstream network.) >>>> >>>> If any relay receives a failure transaction response to a SEND >>>> request where failure reports are requested, that device MUST send a >>>> failure report. If the sending device receives a failure transaction >>>> response, it acts the same as if it had received a failure report >>>> with the same information. Furthermore, if any such device >>>> determines that delivery to the next hop has failed because either a >>>> transport error or a locally defined timeout period has expired >>>> before receiving a 200 OK response, it MUST act as if it had >>>> received an appropriate error response. >>>> >>>> _______________________________________________ >>>> 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-bounces@ietf.org Thu Jun 17 04:40:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10450 for ; Thu, 17 Jun 2004 04:40:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BasRs-0001Wi-On for simple-archive@ietf.org; Thu, 17 Jun 2004 04:40:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BasQt-00018r-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 04:39:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BasPv-0000fB-00; Thu, 17 Jun 2004 04:38:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BasKm-00085e-CR; Thu, 17 Jun 2004 04:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BasFu-0006se-AQ for simple@megatron.ietf.org; Thu, 17 Jun 2004 04:28: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 EAA09578 for ; Thu, 17 Jun 2004 04:28:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BasFp-0004uC-CP for simple@ietf.org; Thu, 17 Jun 2004 04:28:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BasEv-0004X2-00 for simple@ietf.org; Thu, 17 Jun 2004 04:27:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BasE1-0004Au-00 for simple@ietf.org; Thu, 17 Jun 2004 04:26:21 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5H8QHN11782; Thu, 17 Jun 2004 11:26:17 +0300 (EET DST) X-Scanned: Thu, 17 Jun 2004 11:26:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5H8QEto007900; Thu, 17 Jun 2004 11:26:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00xc5OZN; Thu, 17 Jun 2004 11:24:42 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5H8OeH29892; Thu, 17 Jun 2004 11:24:41 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Jun 2004 11:24:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Jun 2004 11:24: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: delivery reports and transaction responses Date: Thu, 17 Jun 2004 11:24:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C84@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: delivery reports and transaction responses Thread-Index: AcRUATVSjnudp9fATsWtklzfGnf38AAQlz1g To: , X-OriginalArrivalTime: 17 Jun 2004 08:24:39.0560 (UTC) FILETIME=[885E3080:01C45444] Content-Transfer-Encoding: quoted-printable Cc: bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I don't like the idea of having a 3rd flag. The flags are clearly for = the sender to indicate the desire to receive DSNs or not. The = transactional responses are a consequence of that choice. We should not = mix that with transactional response flags. Also I don't believe it is a = good idea to give the sender the ability to control when responses are = sent, especially when they are useless and don't give any extra = information to the sender nor to the relays, but instead cause useless = traffic to flow in the network. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 17.June.2004 03:07 > To: Mike Hammer > Cc: Ben Campbell; Simple WG > Subject: Re: [Simple] MSRP: delivery reports and transaction responses >=20 >=20 > When I read the proposal I had a similar reaction to what Mike had. I=20 > was going to comment but decided it was good enough so I=20 > would leave it=20 > be. But since Mike was troubled by the same thing I will support him: >=20 > It would be clearer if there were three flags rather than=20 > two, with the=20 > the third explicitly controlling the sending of responses. This does=20 > permit some nonsense combinations, but they can be simply declared=20 > illegal. (And if anyone uses a nonsense combination they will=20 > get what=20 > they deserve.) And with three flags, they would all be binary. >=20 > Paul >=20 > Mike Hammer wrote: > > The use of the terms sender and recipient could be=20 > endpoints or relays,=20 > > depending on whether you are talking hop-by-hop or=20 > end-to-end. So, I am=20 > > a bit fuzzy until some more precise language is provided. =20 > Otherwise, I=20 > > am guessing as to exactly what you intended. Your fist paragraph=20 > > indicates that reports are endpoint only, and thus omits=20 > any discussion=20 > > of relays. But, then the report failure flag includes=20 > relay behavior=20 > > reactions. Thus, my uncertainty and guessing. > >=20 > > However, either way, the overall behavior could be the same=20 > using three=20 > > flags instead of two. The suggestions were to help confirm=20 > for myself=20 > > that I had read your intent correctly. > >=20 > > Mike > >=20 > >=20 > > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: > >=20 > >> First, just to make sure things are clear, this was not=20 > proposed draft=20 > >> verbiage, it was just a quick descripiton of the approach.=20 > Not only=20 > >> will the draft language be more precise, we will be splitting the=20 > >> endpoint vs. relay behavior between the appropriate drafts. > >> > >> Further comments inline: > >> > >> Mike Hammer wrote: > >> > >>> Ben, > >>> It seems like you could simplify things further if you=20 > de-coupled the=20 > >>> reports from the responses described in your last 4 paragraphs. > >> > >> > >> Do you mean decouple the behavior, or decouple the=20 > descriptions? If=20 > >> the first, please let me know what you have in mind. > >> > >> This > >> > >>> would also help support the clarity you seek in the first=20 > paragraph=20 > >>> and enable some symmetry in having only binary flags. (Having a=20 > >>> 'tricky' part is the first clue to complexity.) > >>> It would also help if you define the behavior upon=20 > receiving the SEND=20 > >>> with each flag for each device type (senders, endpoints, relays,=20 > >>> gateways, recipients -- a non-redundant set would help=20 > readability). > >>> Lumping two flags or device types in one sentence makes=20 > parsing more=20 > >>> difficult. > >> > >> > >> The drafts will do that. > >> > >>> Mike > >>> > >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: > >>> > >>>> In Boston, we had a proposal for a comprimise solution=20 > on handling=20 > >>>> delivery reports and transaction responses. The primary=20 > contributors=20 > >>>> have had a number of discussions, and came up with some details.=20 > >>>> This does not address questions of DSN format, nor does it talk=20 > >>>> about DSN reports that occur after a session has=20 > ended--those will=20 > >>>> be shortly forthcoming. This note only addresses when to=20 > send DSN=20 > >>>> reports and transaction responses, and the relationship=20 > between them. > >>>> > >>>> ----------------------- > >>>> > >>>> First, a clarification of terms. When we use the term "delivery=20 > >>>> report" (or "reports" for short), we mean a report sent=20 > back to the=20 > >>>> sender to tell it the delivery status. This is different than=20 > >>>> "transaction responses" (or "responses" for short). Transaction=20 > >>>> responses to SEND requests are strictly hop-by-hop,=20 > while delivery=20 > >>>> reports are generally end-to-end, or middle-to-end if=20 > the reporting=20 > >>>> device is a relay. > >>>> > >>>> The sender requests delivery reports on a message by=20 > message basis.=20 > >>>> This is done in an MSRP header in a SEND request. That=20 > header has=20 > >>>> two distinct flags. One indicates the desire to get=20 > failure reports,=20 > >>>> and the other indicates the desire to get success reports. The=20 > >>>> sender can set any combination of these flags. > >>>> > >>>> The success report request flag can have values of true=20 > or false. If=20 > >>>> the flag is true, then the receiving endpoint MUST send back a=20 > >>>> success report when it successfully receives a message.=20 > This does=20 > >>>> not say anything about the message disposition after=20 > reception, only=20 > >>>> that is was successfully received. If this flag is false, the=20 > >>>> receiving endpoint MUST NOT send success reports.=20 > Success reports=20 > >>>> are strictly end-to-end, that is, Relays _never_ send=20 > success reports. > >>>> > >>>> The failure report request flag can have three values:=20 > True, False,=20 > >>>> and "partial". If this flag is false, then both the receiving=20 > >>>> endpoint and any relays MUST NOT send failure reports. If it is=20 > >>>> "partial", then the receiving device and any relay=20 > SHOULD send an=20 > >>>> error report if it detects a "fatal" error; that is, an=20 > error which=20 > >>>> prevents delivery of the message. > >>>> > >>>> Now, here is the tricky part: None of the conditions=20 > described so=20 > >>>> far involve the use of transaction responses to SEND=20 > requests. If=20 > >>>> the failure report request flag is any value other than=20 > True, then=20 > >>>> MSRP devices SHOULD NOT send transaction responses for=20 > the request.=20 > >>>> Furthermore, devices MUST NOT "expect" transaction responses,=20 > >>>> although they should not freak out if they get one. > >>>> > >>>> If the failure report request flag is True, then the=20 > recipient, and=20 > >>>> any relays, MUST send send a transaction response. If any device=20 > >>>> detects an error which prevents delivery, it SHOULD send=20 > a failure=20 > >>>> transaction response back to the previous hop. If it is=20 > unable to=20 > >>>> immediately detect the error, it MAY send a 200 OK response,=20 > >>>> followed by a failure _report_ when the error is=20 > detected. (This is=20 > >>>> mainly for gateway devices, which may not notice the error until=20 > >>>> they are informed by the downstream network.) > >>>> > >>>> If any relay receives a failure transaction response to a SEND=20 > >>>> request where failure reports are requested, that device=20 > MUST send a=20 > >>>> failure report. If the sending device receives a failure=20 > transaction=20 > >>>> response, it acts the same as if it had received a=20 > failure report=20 > >>>> with the same information. Furthermore, if any such device=20 > >>>> determines that delivery to the next hop has failed=20 > because either a=20 > >>>> transport error or a locally defined timeout period has expired=20 > >>>> before receiving a 200 OK response, it MUST act as if it had=20 > >>>> received an appropriate error response. > >>>> > >>>> _______________________________________________ > >>>> 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 >=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-bounces@ietf.org Thu Jun 17 06:01:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15032 for ; Thu, 17 Jun 2004 06:01:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BatiF-0006uX-L5 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:01:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BathM-0006Xv-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:00:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BatgV-0005qF-00; Thu, 17 Jun 2004 05:59:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BataO-00083X-JF; Thu, 17 Jun 2004 05:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BatYR-0007UH-IY for simple@megatron.ietf.org; Thu, 17 Jun 2004 05:51: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 FAA14534 for ; Thu, 17 Jun 2004 05:51:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BatYM-0003Se-H7 for simple@ietf.org; Thu, 17 Jun 2004 05:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BatXS-00037p-00 for simple@ietf.org; Thu, 17 Jun 2004 05:50:31 -0400 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly04a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BatWs-0002li-00 for simple@ietf.org; Thu, 17 Jun 2004 05:49:54 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly04a.srv.mailcontrol.com (MailControl) with SMTP id i5H9mmBE001489; Thu, 17 Jun 2004 10:49:05 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 17 Jun 2004 10:49:21 +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: delivery reports and transaction responses Date: Thu, 17 Jun 2004 10:48:52 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF4AA@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: delivery reports and transaction responses Thread-Index: AcRUATVSjnudp9fATsWtklzfGnf38AAQlz1gAAMYVVA= From: "Chris Boulton" To: , , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Cc: bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I'm with Hisham on this - I think a third flag would just confuse the process. It has been identified that transaction responses are only really needed in one DSN request state (negative=3Dtrue) - why have a third flag to convey this? Chris. > >I don't like the idea of having a 3rd flag. The flags are clearly for the >sender to indicate the desire to receive DSNs or not. The transactional >responses are a consequence of that choice. We should not mix that with >transactional response flags. Also I don't believe it is a good idea to >give the sender the ability to control when responses are sent, especially >when they are useless and don't give any extra information to the sender >nor to the relays, but instead cause useless traffic to flow in the >network. > >Regards, >Hisham > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf >> Of ext Paul Kyzivat >> Sent: 17.June.2004 03:07 >> To: Mike Hammer >> Cc: Ben Campbell; Simple WG >> Subject: Re: [Simple] MSRP: delivery reports and transaction responses >> >> >> When I read the proposal I had a similar reaction to what Mike had. I >> was going to comment but decided it was good enough so I >> would leave it >> be. But since Mike was troubled by the same thing I will support him: >> >> It would be clearer if there were three flags rather than >> two, with the >> the third explicitly controlling the sending of responses. This does >> permit some nonsense combinations, but they can be simply declared >> illegal. (And if anyone uses a nonsense combination they will >> get what >> they deserve.) And with three flags, they would all be binary. >> >> Paul >> >> Mike Hammer wrote: >> > The use of the terms sender and recipient could be >> endpoints or relays, >> > depending on whether you are talking hop-by-hop or >> end-to-end. So, I am >> > a bit fuzzy until some more precise language is provided. >> Otherwise, I >> > am guessing as to exactly what you intended. Your fist paragraph >> > indicates that reports are endpoint only, and thus omits >> any discussion >> > of relays. But, then the report failure flag includes >> relay behavior >> > reactions. Thus, my uncertainty and guessing. >> > >> > However, either way, the overall behavior could be the same >> using three >> > flags instead of two. The suggestions were to help confirm >> for myself >> > that I had read your intent correctly. >> > >> > Mike >> > >> > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: >> > >> >> First, just to make sure things are clear, this was not >> proposed draft >> >> verbiage, it was just a quick descripiton of the approach. >> Not only >> >> will the draft language be more precise, we will be splitting the >> >> endpoint vs. relay behavior between the appropriate drafts. >> >> >> >> Further comments inline: >> >> >> >> Mike Hammer wrote: >> >> >> >>> Ben, >> >>> It seems like you could simplify things further if you >> de-coupled the >> >>> reports from the responses described in your last 4 paragraphs. >> >> >> >> >> >> Do you mean decouple the behavior, or decouple the >> descriptions? If >> >> the first, please let me know what you have in mind. >> >> >> >> This >> >> >> >>> would also help support the clarity you seek in the first >> paragraph >> >>> and enable some symmetry in having only binary flags. (Having a >> >>> 'tricky' part is the first clue to complexity.) >> >>> It would also help if you define the behavior upon >> receiving the SEND >> >>> with each flag for each device type (senders, endpoints, relays, >> >>> gateways, recipients -- a non-redundant set would help >> readability). >> >>> Lumping two flags or device types in one sentence makes >> parsing more >> >>> difficult. >> >> >> >> >> >> The drafts will do that. >> >> >> >>> Mike >> >>> >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >> >>> >> >>>> In Boston, we had a proposal for a comprimise solution >> on handling >> >>>> delivery reports and transaction responses. The primary >> contributors >> >>>> have had a number of discussions, and came up with some details. >> >>>> This does not address questions of DSN format, nor does it talk >> >>>> about DSN reports that occur after a session has >> ended--those will >> >>>> be shortly forthcoming. This note only addresses when to >> send DSN >> >>>> reports and transaction responses, and the relationship >> between them. >> >>>> >> >>>> ----------------------- >> >>>> >> >>>> First, a clarification of terms. When we use the term "delivery >> >>>> report" (or "reports" for short), we mean a report sent >> back to the >> >>>> sender to tell it the delivery status. This is different than >> >>>> "transaction responses" (or "responses" for short). Transaction >> >>>> responses to SEND requests are strictly hop-by-hop, >> while delivery >> >>>> reports are generally end-to-end, or middle-to-end if >> the reporting >> >>>> device is a relay. >> >>>> >> >>>> The sender requests delivery reports on a message by >> message basis. >> >>>> This is done in an MSRP header in a SEND request. That >> header has >> >>>> two distinct flags. One indicates the desire to get >> failure reports, >> >>>> and the other indicates the desire to get success reports. The >> >>>> sender can set any combination of these flags. >> >>>> >> >>>> The success report request flag can have values of true >> or false. If >> >>>> the flag is true, then the receiving endpoint MUST send back a >> >>>> success report when it successfully receives a message. >> This does >> >>>> not say anything about the message disposition after >> reception, only >> >>>> that is was successfully received. If this flag is false, the >> >>>> receiving endpoint MUST NOT send success reports. >> Success reports >> >>>> are strictly end-to-end, that is, Relays _never_ send >> success reports. >> >>>> >> >>>> The failure report request flag can have three values: >> True, False, >> >>>> and "partial". If this flag is false, then both the receiving >> >>>> endpoint and any relays MUST NOT send failure reports. If it is >> >>>> "partial", then the receiving device and any relay >> SHOULD send an >> >>>> error report if it detects a "fatal" error; that is, an >> error which >> >>>> prevents delivery of the message. >> >>>> >> >>>> Now, here is the tricky part: None of the conditions >> described so >> >>>> far involve the use of transaction responses to SEND >> requests. If >> >>>> the failure report request flag is any value other than >> True, then >> >>>> MSRP devices SHOULD NOT send transaction responses for >> the request. >> >>>> Furthermore, devices MUST NOT "expect" transaction responses, >> >>>> although they should not freak out if they get one. >> >>>> >> >>>> If the failure report request flag is True, then the >> recipient, and >> >>>> any relays, MUST send send a transaction response. If any device >> >>>> detects an error which prevents delivery, it SHOULD send >> a failure >> >>>> transaction response back to the previous hop. If it is >> unable to >> >>>> immediately detect the error, it MAY send a 200 OK response, >> >>>> followed by a failure _report_ when the error is >> detected. (This is >> >>>> mainly for gateway devices, which may not notice the error until >> >>>> they are informed by the downstream network.) >> >>>> >> >>>> If any relay receives a failure transaction response to a SEND >> >>>> request where failure reports are requested, that device >> MUST send a >> >>>> failure report. If the sending device receives a failure >> transaction >> >>>> response, it acts the same as if it had received a >> failure report >> >>>> with the same information. Furthermore, if any such device >> >>>> determines that delivery to the next hop has failed >> because either a >> >>>> transport error or a locally defined timeout period has expired >> >>>> before receiving a 200 OK response, it MUST act as if it had >> >>>> received an appropriate error response. >> >>>> >> >>>> _______________________________________________ >> >>>> 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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 06:34:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16545 for ; Thu, 17 Jun 2004 06:34:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauDw-0002XF-SW for simple-archive@ietf.org; Thu, 17 Jun 2004 06:34:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauBy-0001ou-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:32:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BauA4-0000tb-00; Thu, 17 Jun 2004 06:30:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau6B-0006aJ-Dc; Thu, 17 Jun 2004 06:26:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Batzc-0005sg-H2 for simple@megatron.ietf.org; Thu, 17 Jun 2004 06:19: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 GAA15803 for ; Thu, 17 Jun 2004 06:19:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BatzX-0005Ld-7U for simple@ietf.org; Thu, 17 Jun 2004 06:19:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BatyZ-0004zc-00 for simple@ietf.org; Thu, 17 Jun 2004 06:18:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Batxi-0004IJ-00 for simple@ietf.org; Thu, 17 Jun 2004 06:17:38 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HAHNbo025827; Thu, 17 Jun 2004 06:17:24 -0400 (EDT) Message-ID: <40D16F98.6000404@dynamicsoft.com> Date: Thu, 17 Jun 2004 06:16:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] XCAP List Issue 2: Whither URI References: <40C99509.1030400@dynamicsoft.com> <40CD4FA1.9030305@nokia.com> In-Reply-To: <40CD4FA1.9030305@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. Miguel Garcia wrote: > Jonathan: > > One issue that makes me think a child element will have advantages is > the case when there are several URIs representing an entry, for instance > a sip and press or im URIs. What would that mean, in terms of list subscriptions? Would each of them get subscribed to? I don't think thats what you intend. It may very well be that there are multiple URIs, but they each probably have a different meaning. > > If you represent the URI as an attribute then you can't have repetitions > of the same attribute. However, if you represent the URI as an element > you can have repetitions, for example: > > > sip:user@example.com > pres:user@example.com > Joe User > > > If you have an attribute, you will need to create a new entry per URI, > and that might not be so efficient. You can have the best of both. You could define a URI attribute. This URI is the address of record for the user, and it represents the URI that would be used to subscribe to that user in the case of a buddy list subscription. If you had additional information about that user, for example, a pres URI, IM URI, or tel URI, you would include those as informational elements within the entry. So: im:user@example.com tel:+17325551212 Joe User What I want to make sure of, is that the basic case which we are most concerned about (a single URI, used for list subscriptions), works well and efficiently, including the ad-hoc case. 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-bounces@ietf.org Thu Jun 17 06:36:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16754 for ; Thu, 17 Jun 2004 06:36:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauFp-0003GT-E3 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:36:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauEq-0002t5-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:35:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BauCz-0001sb-00; Thu, 17 Jun 2004 06:33:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau6D-0006au-Qx; Thu, 17 Jun 2004 06:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau0V-00061X-D6 for simple@megatron.ietf.org; Thu, 17 Jun 2004 06:20: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 GAA15879 for ; Thu, 17 Jun 2004 06:20:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bau0Q-0005hX-6T for simple@ietf.org; Thu, 17 Jun 2004 06:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Batzg-0005N8-00 for simple@ietf.org; Thu, 17 Jun 2004 06:19:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Batz4-0004zm-00 for simple@ietf.org; Thu, 17 Jun 2004 06:19:02 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HAItbo025830; Thu, 17 Jun 2004 06:18:55 -0400 (EDT) Message-ID: <40D16FF3.1090505@dynamicsoft.com> Date: Thu, 17 Jun 2004 06:18:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <40C99698.3070609@dynamicsoft.com> In-Reply-To: <40C99698.3070609@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit No comments on this? -Jonathan R. Jonathan Rosenberg wrote: > Currently, the resource list format has two attributes for each . > The are the optional name, and mandatory URI parameter. The name exists > solely as an alternative index useful for XCAP selection of entries. > However, do we really need TWO indices? > > The main concern around using the URI as an index is that URI > comparisons are more compelx than just string match, and if we use the > URI as an index for XCAP selection, the element would be selected based > on string equality (case sensitive, I believe). However, its possible > for two URI to be unequal by case sensitive string comparison, and equal > by URI equality. More interestingly, I think it is the case that if two > URI are equal by case sensitive string compare, then they will also be > equal by URI comparison rules. The implication is that I will always be > able to select the entry I want (i.e., there won't be ambiguity), but > the XCAP rules may allow me to have two entries that have the same URI > by URi equality rules, just because they differ by case sensitive string > comparison. > > I don't think thats a particularly bad limitation (indeed, one might > even argue that its a feature). As such, I'd propose to drop the name > attribute entirely. > > Note that the specification does need to also clarify that each > has to have a unique uri attribute amongst its siblings. It doesnt say > that now. This means that the server will reject, with a 409, a request > to add an if its uri attribute is not unique. > > -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-bounces@ietf.org Thu Jun 17 06:39:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16969 for ; Thu, 17 Jun 2004 06:39:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauIl-0004Ns-8g for simple-archive@ietf.org; Thu, 17 Jun 2004 06:39:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauHy-00041H-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:38:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BauH9-0003XO-00; Thu, 17 Jun 2004 06:37:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau9J-0007Cb-Pd; Thu, 17 Jun 2004 06:29:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau1V-0006CH-4P for simple@megatron.ietf.org; Thu, 17 Jun 2004 06:21:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15896 for ; Thu, 17 Jun 2004 06:21:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bau1P-00062T-UE for simple@ietf.org; Thu, 17 Jun 2004 06:21:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bau0Q-0005hc-00 for simple@ietf.org; Thu, 17 Jun 2004 06:20:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bau01-0005Le-00 for simple@ietf.org; Thu, 17 Jun 2004 06:20:01 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HAJsbo025833; Thu, 17 Jun 2004 06:19:54 -0400 (EDT) Message-ID: <40D1702E.7010504@dynamicsoft.com> Date: Thu, 17 Jun 2004 06:19:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 4: List URI uniqueness References: <40C99C0A.5070802@dynamicsoft.com> In-Reply-To: <40C99C0A.5070802@dynamicsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i5HAJsbo025833 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Folks, This proposal here represents a pretty important change that we could=20 make to the list handling; one that I think we should make. Please take=20 a look and comment. Thanks, Jonathan R. Jonathan Rosenberg wrote: > The main purpose of the resource list XML schema is to define the=20 > resource lists that you can subscribe to using the SIP event extension=20 > for resource lists=20 > (http://www.watersprings.org/pub/id/draft-ietf-simple-event-list-04.txt= ). >=20 > This means that the SIP URI identifying each resource list needs to be=20 > unique on the server. Unfortunately, those URI exist buried within each= =20 > resource list document. This makes it hard to, at the time a resource=20 > list is added or changed, check to see that the list URI is unique. >=20 > Similarly, when a resource list server (the SIP server handling=20 > SUBSCRIBE requests for the list) receives a SUBSCRIBE to a list, there=20 > isn't a clear document to go to that indicates the contents of that lis= t. >=20 > In other words, the SIP URI for the resource lists is meaningful as an=20 > index, but it doesnt appear anywhere in the schemas as an index. >=20 > There are two solutions to this problem: >=20 > Approach I: Leave it alone. Let the XCAP servers maintain this index on= =20 > their own. It does mean that that there isn't an easy way for the=20 > resource list server to fetch the contents of the list from the XCAP=20 > server in a standard way. >=20 > Approach II: We can define a new application usage, which is the actual= =20 > set of resource list URIs you can subscribe to. There would be a single= =20 > instance of this document for each user. That would contain the list of= =20 > URIs defined by that user as subscribeable resource lists. For each URI= ,=20 > there would be a reference into their actual hierarchy of and=20 > s as defined by the current schema in the existing doc. For exam= ple: >=20 > > > http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/ > resource-lists/list[@name=3D=93co-workers=94] > > >=20 > We would, as a result of this, remove the "subscribeable" flag from the= =20 > current schema, along with the URI attribute for the element. >=20 > In addition to there being a single instance of a document for each=20 > user, there would also be a single instance of a document for the entir= e=20 > server. This document would be in the global tree, readable only by=20 > resource lists servers. It basically contains the union of all of the=20 > documents for the individual users. This would allow a resource list=20 > server to do a single query to obtain the HTTP URI that defines the=20 > membership of the list. For example, if an RLS got a SUBSCRIBE request=20 > for sip:friends@example.com, it would do the following XCAP query to ge= t=20 > the XCAP URI pointing to the membership: >=20 > GET=20 > http://xcap.server.com/xcap-root/list-of-lists/global/thelist/~~/sip-ur= is/ > list[@uri=3D"sip:friends@example.com"] >=20 > and the 200 OK: >=20 > 200 OK > Content-Type: application/xml >=20 > > http://www.example.com/xcap/resource-lists/users/a/obuddies/=0B=20 > resource-lists/list[@name=3D=93co-workers=94] > >=20 > Now it can do this: >=20 > GET http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/ > resource-lists/list[@name=3D=93co-workers=94] >=20 > and get back: > 200 OK > Content-Type: application/xml >=20 > > > Bill Doe > > > > Joe Smith > > > Nancy Gross > > http://www.example.org/xcap/resource-lists/users/a/foo > > > >=20 >=20 > and the result is the list of URIs the RLS needs to subscribe to. >=20 >=20 > I really like approach 2. It clearly separates the SIP activities=20 > associated with a list, from the set of users that make up the list. It= =20 > provides a concrete place where the index of buddy lists will live, bot= h=20 > for each user and for all users. It seems to work better for ad-hoc=20 > lists two. The thing carried in the body of the SUBSCRIBE or INVITE or=20 > MESSAGE or whatever, which identifies the ad-hoc list, is only the=20 > structure set of users. The "subscribeable" flag would make no sense in= =20 > that context, for example, and with this proposal, it would be removed. >=20 > Note that a change to the list for a single user would need to be=20 > automatically reflected in the global list by the server. >=20 > I'd propose making this change. I think we need to define both=20 > application usages up front, since we can't satisfy our driving=20 > requirement (define a way to create buddy lists for SIP resource list=20 > subscriptions) without both. I would do them both in the same document=20 > however. >=20 > Comments? >=20 > Thanks, > Jonathan R. --=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 06:45:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17346 for ; Thu, 17 Jun 2004 06:45:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauOS-0006V5-Bw for simple-archive@ietf.org; Thu, 17 Jun 2004 06:45:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauNT-0006A4-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 06:44:16 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BauMP-0005WI-00; Thu, 17 Jun 2004 06:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau9R-0007EZ-5m; Thu, 17 Jun 2004 06:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bau5F-0006UJ-80 for simple@megatron.ietf.org; Thu, 17 Jun 2004 06:25: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 GAA15997 for ; Thu, 17 Jun 2004 06:25:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bau59-0007Lu-VD for simple@ietf.org; Thu, 17 Jun 2004 06:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bau4B-00071u-00 for simple@ietf.org; Thu, 17 Jun 2004 06:24:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bau3d-0006hY-00 for simple@ietf.org; Thu, 17 Jun 2004 06:23:45 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HANcbo025836; Thu, 17 Jun 2004 06:23:38 -0400 (EDT) Message-ID: <40D1710F.80602@dynamicsoft.com> Date: Thu, 17 Jun 2004 06:23:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP List Issue 1: External Reference Scope References: <2038BCC78B1AD641891A0D1AE133DBB701797C5C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C5C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Right, good point. In all cases you have a problem with referential integrity. Options 1 and 3 have other problems too though. I think that, if the reference list cannot be accessed, the behavior depends on the application using the document. To be clear, it is NOT my assumption that the xcap server would resolve this reference when returning the content of the document. In other words, if I fetch, using XCAP, a list, and that list includes an entry reference, the server would return the list with the reference. It would not replace that reference with the actual entry being referred to. This is not a database join operation. If the application is a buddy list server (aka resource list server, RLS), it would just ignore that entry and not attempt a subscription to it. -Jonathan R. hisham.khartabil@nokia.com wrote: > 2 is OK, but you still need some text defining the behaviour when the referenced list cannot be accessed (has been removed, etc). > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Jonathan Rosenberg >>Sent: 11.June.2004 14:14 >>To: Simple WG >>Subject: [Simple] XCAP List Issue 1: External Reference Scope >> >> >>This issue was raised some time ago, by Hisham I think, and >>has yet to >>be resolved. I had slides on this (and the other list issues) >>prepared >>for the interim, but we didnt get to it. >> >>The resource list schema includes an element >>which contains >>a reference to another entry. The purpose of this is to avoid >>entering >>duplicate data about a user when that user appears on multiple buddy >>lists. The content of this element is a reference to an >> element. >>The question is, what is the scope of this reference? Is it: >> >>1. an HTTP URI representing an XCAP resource that is an >> element >>on this server or another server, in this domain or another domain >>(i.e., >>http://server.example.com/xcap-root/resource-lists/users/jdrosen/doc1/ >>~~/resource-lists/list/entry >> >> >>2. a path from the XCAP root services URI, pointing to an >>element on this server (i.e., "/resource-lists/users/jdrosen/doc1/ >>~~/resource-lists/list/entry" >> >>3. a path from the current document, pointing to an >>element in >>the same document (i.e., "/resource-lists/list/entry" >> >> >>I think doing (1) introduces all kinds of hairy issues around >>authorization (you'd need to define policies about who can look at >>specific entries in your lists) and referential integrity. I think 3 >>gives insufficient flexibility. I'd like to be able to have a company >>list of users, and define by buddy list as a series of references to >>that central list. As such, I'd propose 2. >> >>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-bounces@ietf.org Thu Jun 17 07:08:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18876 for ; Thu, 17 Jun 2004 07:08:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bauky-00076s-NR for simple-archive@ietf.org; Thu, 17 Jun 2004 07:08:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bauk6-0006bR-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 07:07:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bauia-00063o-00; Thu, 17 Jun 2004 07:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baues-000851-Tq; Thu, 17 Jun 2004 07:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BauTq-0004U3-Mr for simple@megatron.ietf.org; Thu, 17 Jun 2004 06:50: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 GAA17604 for ; Thu, 17 Jun 2004 06:50:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauTl-0000Qz-BP for simple@ietf.org; Thu, 17 Jun 2004 06:50:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauRk-0007Yh-00 for simple@ietf.org; Thu, 17 Jun 2004 06:48:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BauR7-0007C6-00 for simple@ietf.org; Thu, 17 Jun 2004 06:48:01 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HAlsbo025841; Thu, 17 Jun 2004 06:47:55 -0400 (EDT) Message-ID: <40D176BF.1010709@dynamicsoft.com> Date: Thu, 17 Jun 2004 06:47:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops References: <2038BCC78B1AD641891A0D1AE133DBB701797C48@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C48@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >> -----Original Message----- From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf Of ext Jonathan Rosenberg >> Sent: 10.June.2004 10:12 To: Simple WG Subject: [Simple] XCAP >> Issue 7 Interim Summary: uniqueness in intermediatehops >> >> >> This is an issue raised by Joel and discussed on the list. The >> problem was whether or not we would require the URI to select a >> unique element at each hop of its evaluation, or just make sure the >> final result of selection was unique. >> >> If you are implementing XCAP without an XPATH library, this is a >> really nice feature to have. There is code and computational >> complexity if its not there. If you have an XPATH library, its a >> constraint that you need to explicitly verify outside of the xpath >> library, since XPATH does allow non-uniqueness at each hop. >> >> There were continuing objections to the complexity introduced if >> each hop is not unique. As such, there was consensus on the >> uniqueness requirement. >> >> However, Henning had a proposal to take this a step further. His >> proposal was that we could constrain XCAP so that at each step, you >> were selecting an element based on a unique index that was declared >> by the application usage to be unique. This way, you couldn't even >> ever have an expression which selected multiple things at each >> step. Here's an example to explain. Lets say we've got a schema >> that has a parent element called , and can have one or >> more children, each named . So, the following is a valid >> document: >> >> >> >> And thus, the expression "foo/bar" selects the element, and >> also gives you a single element at each step. Thus, it would be >> valid. However, in Hennings proposal, this expression would be >> illegal, since it might be the case that is not unique, and >> thus it could be the case that tbe expression "foo/bar" does not >> resolve to something unique. In such a case, the schema would have >> to mandate that each bar element have an attribute called "id" (for >> example), and that the application usage would mandate that this >> attribute be unique amongst all siblings. If you do that, then you >> can be guaranteed that the expression: >> >> foo/bar[@id="223"] >> >> is unique. It may not point to anything, but if it does, it points >> to only one element. >> >> Henning, if I have mis-interpreted your proposal, let me know. >> >> This proposal was further refined. The idea was that an element >> needs to have a unique index only if it can appear more than once >> in the document. If it can appear only once, you don't need to >> define a unique attribute for it. >> >> Upon further consideration, I concluded that the refined proposal >> was not a good idea. The objective of what Henning was proposing is >> that a server could look at the URI, and without needing to know >> the schema or even the instance document, determine whether the URI >> resolved to something unique. Of course, it could still resolve to >> nothing if any one of the indices didn't exist in the instance >> document. With the refined proposal, the server would need to know >> the schema to determine whether the URI was unique. > > > No it doesn't. The server can still do the dynamic checking of the > instance document. Having refined proposal will aid in eliminating > the possibility of failure. Once you have committed to do the dynamic checking of the document, why not just deal with the failure case? You already need to deal with the failure case that there may be no instances of an element, even though one is requested in a GET. Why is that harder than dealing with the case that there are more than one? If you try and eliminate it by introducing rules into the structure of the document (that is, impose rules on the schemas for XCAP managed documents), you make it so that xcap can NEVER be used to manage documents whose schema doesn't match the requirements. > > eg: if we have > > > > then /foo/bar/baz expression is not unique at every step and > therefore I can never ever modify . Right. In none of the proposals on the table would you be able to modify baz if a document looks like this. > > If we define that "an element needs to have a unique index only if it > can appear more than once in the document. If it can appear only > once, you don't need to define a unique attribute for it", then the > server can still do the dynamic checking (if it does not trust the > client) and it enables the client to modify some parts of the > instance document that are otherwise unmodifiable. I don't understand. None of the proposals differ in terms of making it possible to modify something that isn't modifiable in one of the other proposals. In the technique you are advocating, we would introduce this rule that an element can appear once in a doc, and if it appears more than once, has to have a unique index. This can be enforced by mandating that XCAP-managebale documents have to have schemas with this constraint. I think that is too limiting. Perhaps you are instead advocating that we don't introduce this constraint into the schema, but rather, instance documents. I still think thats too limiting. We may have documents that have two elements with the same name and no unique attributes, but there isn't a need to modify at that level; you would only be able to modify the document by addressing elements that are ancestors of the pair. Thats fine. So, I'm saying, allow documents to look this way, but you'll get an error if you try and address below this point in the document where the pair exists. Of course, if there is only one element with the name in the document, you can address deeper. In your proposal, you are just trying to eliminate the case where a document ever has two elements with the same name and non-unique attributes; in the approach I prefer, you allow the case but don't allow addressing below that level. In neither case can you address into a document below a set of non-uniquely-identifiable elements. I think its fine to have a guideline which recommends that a client needs to use unique attributes when creating documents where it wants to address those elements or below. But, this is nothing more than a guideline. -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-bounces@ietf.org Thu Jun 17 07:14:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19378 for ; Thu, 17 Jun 2004 07:14:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bauqu-0001Yy-67 for simple-archive@ietf.org; Thu, 17 Jun 2004 07:14:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bauq0-0001Cj-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 07:13:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Baup4-0000bY-00; Thu, 17 Jun 2004 07:12:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bauey-00087W-UR; Thu, 17 Jun 2004 07:02:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BauXP-00056b-Ke for simple@megatron.ietf.org; Thu, 17 Jun 2004 06:54: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 GAA17739 for ; Thu, 17 Jun 2004 06:54:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauXK-0001pG-EH for simple@ietf.org; Thu, 17 Jun 2004 06:54:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauWI-0001Ud-00 for simple@ietf.org; Thu, 17 Jun 2004 06:53:23 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BauVr-00019V-00 for simple@ietf.org; Thu, 17 Jun 2004 06:52:55 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HAqmbo025844; Thu, 17 Jun 2004 06:52:48 -0400 (EDT) Message-ID: <40D177E4.3070402@dynamicsoft.com> Date: Thu, 17 Jun 2004 06:52:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] XCAP Issue 4 Interim Summary: document to element separator References: <40C7FC2A.5080405@dynamicsoft.com> <1086872390.7949.36.camel@xitami.research.nokia.com> In-Reply-To: <1086872390.7949.36.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jari Urpalainen wrote: > On Thu, 2004-06-10 at 09:14, ext Jonathan Rosenberg wrote: > >>This is the micro-issue that won't die. >> >>I had proposed the single quote as another choice. However, there was >>concern that implementors would get this wrong, given the different >>types of single quotes. It was pointed out that the separator doesnt >>have to be a single character. So, "~~" was proposed (two tildes). This >>seemed fine, and there was consensus to use that as the separator. >> >>Thanks, >>Jonathan R. > > > As Joel already noted that ~ is allowed in some ;) operating systems as > a valid directory this applies to double tildes (file/directory) too. Of > course the probability of having this sort of an error is rare it may > happen. If this is still introduced the situation should at least be > warned in the draft. We need to keep in mind that XCAP is all about defining the structure of a URI and defining the resource it identifies. Thus, its not like you are going to see arbitrary URIs. We can simply mandate that no path in the directory have the name "~~". The concern was around the possibility of transparent proxies and other nasties that would not know about xcap, and would rewrite the "~" in a URI to the home directory of a user. This idea was that they wouldn't rewrite a "~~". If we don't worry about that case (transparent proxies rewriting URIs), then we can even use the "~" safely, just by mandating that the XCAP server never allow "~" as a part of the path. Honestly, I'd rather do that and just use the single tilde. -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-bounces@ietf.org Thu Jun 17 08:37:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24921 for ; Thu, 17 Jun 2004 08:37:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Baw8z-0005vH-W7 for simple-archive@ietf.org; Thu, 17 Jun 2004 08:37:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Baw80-0005ab-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 08:36:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Baw6z-0004wY-00; Thu, 17 Jun 2004 08:35:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BavqE-0000ro-OD; Thu, 17 Jun 2004 08:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bavi1-0006qc-TL for simple@megatron.ietf.org; Thu, 17 Jun 2004 08:09: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 IAA22838 for ; Thu, 17 Jun 2004 08:09:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bavi1-0004Ef-CD for simple@ietf.org; Thu, 17 Jun 2004 08:09:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BavhA-0003ue-00 for simple@ietf.org; Thu, 17 Jun 2004 08:08:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BavgM-0003TB-00 for simple@ietf.org; Thu, 17 Jun 2004 08:07:50 -0400 Received: from dynamicsoft.com ([63.113.46.123]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5HC7abo025858; Thu, 17 Jun 2004 08:07:37 -0400 (EDT) Message-ID: <40D1896C.3060408@dynamicsoft.com> Date: Thu, 17 Jun 2004 08:07:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions References: <2038BCC78B1AD641891A0D1AE133DBB701797C38@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C38@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Jonathan, > > Thanks for the analysis. > > Reading your analysis actually brings me to the opposite conclusion > to the one you made. That is, we need positional insertions. There > are so many rules, restriction, and guide lines that need to be > educated to current and future designers of XCAP friendly schemas. > Wouldn't it be a much better investment if we allow positional > insertions now and avoid schema misdesign? I don't think any of the guidelines represent a schema mis-design. > > You haven't explicitly listed the issues with positional insertions, > but instead you listed the problems that it solves. Can you please > educate the rest of us what the real problems are with positional > insertions? It was just complexity. Positional insertions would require us to support multiple predicates (i.e., more than one [] rule). We could restrict it to just two in our case, and indeed, restrict the first predicate to be a positional selector only. I think that might help the complexity a bit. However, there is definitely more logic and code required to support it than not. How much exactly? Depends on the implementation. I'll send a separate note in the next day or so with a pseudo-code view of what a minimal implementation would be, so folks can get a sense of it. The meta-issue was that the whole idea with xcap is that what we are generally doing is reading and writing a document from a server (like a buddy list), but sometimes, you need to read or write a piece of it as an optimization, so we have the notion of sub-document addressing. When you view the design goal as reading and writing of entire documents with sub-document operations as a performance optimization, things like positional inserts teeter on the boundary between this view, and the view of xcap as an XML database protocol. I think that, if we are defining an XML database protocol, we would probably start from a different approach, along the lines of XUpdate. I must say that, on the issue of positional inserts, I am on the fence. I do see the "keep it barebones simple" argument, especially as it relates to the view of xcap as an optimization around reading and writing of documents. On the other hand, from a code perspective, I don't think positional inserts is actually that complicated, and it does, as Hisham pointed out, remove a lot of "schema design guidelines" that I would otherwise need to introduce to deal with it. Comments from others? Even a "do positional inserts" or "dont do it" response is helpful. 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-bounces@ietf.org Thu Jun 17 09:01:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26391 for ; Thu, 17 Jun 2004 09:01:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BawWg-0006Qn-5M for simple-archive@ietf.org; Thu, 17 Jun 2004 09:01:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BawU8-0005U6-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 08:59:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BawT6-000554-01; Thu, 17 Jun 2004 08:58:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BawQK-0005S6-JI; Thu, 17 Jun 2004 08:55:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BawAa-0000BS-5p; Thu, 17 Jun 2004 08:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baw2c-00038O-N9 for simple@megatron.ietf.org; Thu, 17 Jun 2004 08:30: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 IAA24538 for ; Thu, 17 Jun 2004 08:30:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Baw2a-0003ZF-Nn for simple@ietf.org; Thu, 17 Jun 2004 08:30:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Baw1b-0003D5-00 for simple@ietf.org; Thu, 17 Jun 2004 08:29:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Baw0g-0002sC-00 for simple@ietf.org; Thu, 17 Jun 2004 08:28:50 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5HCSgJ01949; Thu, 17 Jun 2004 15:28:44 +0300 (EET DST) X-Scanned: Thu, 17 Jun 2004 15:28:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5HCSdw0025948; Thu, 17 Jun 2004 15:28:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 001kmclY; Thu, 17 Jun 2004 15:28:37 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5HCSWH04951; Thu, 17 Jun 2004 15:28:32 +0300 (EET DST) Received: from nokia.com ([172.17.212.29]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Jun 2004 15:28:29 +0300 Message-ID: <40D188E0.2030304@nokia.com> Date: Thu, 17 Jun 2004 15:04:48 +0300 From: Miguel 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-es MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 2: Whither URI References: <40C99509.1030400@dynamicsoft.com> <40CD4FA1.9030305@nokia.com> <40D16F98.6000404@dynamicsoft.com> In-Reply-To: <40D16F98.6000404@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2004 12:28:29.0596 (UTC) FILETIME=[988C85C0:01C45466] Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan, I think I had in my mind the URI representing the list and not each of the entries as I said in my previous e-mail, my apologies if I missled you. The URI representing the list is not visible in the schema (I believe), so my comment is not applicable. Also, can you provide an example of the XML document? The draft does not contain any. This will help me in understanding the schema. Thanks a lot, Miguel Jonathan Rosenberg wrote: > inline. > > Miguel Garcia wrote: > >> Jonathan: >> >> One issue that makes me think a child element will have advantages is >> the case when there are several URIs representing an entry, for >> instance a sip and press or im URIs. > > > What would that mean, in terms of list subscriptions? Would each of them > get subscribed to? I don't think thats what you intend. It may very well > be that there are multiple URIs, but they each probably have a different > meaning. > >> >> If you represent the URI as an attribute then you can't have >> repetitions of the same attribute. However, if you represent the URI >> as an element you can have repetitions, for example: >> >> >> sip:user@example.com >> pres:user@example.com >> Joe User >> >> >> If you have an attribute, you will need to create a new entry per URI, >> and that might not be so efficient. > > > You can have the best of both. > > You could define a URI attribute. This URI is the address of record for > the user, and it represents the URI that would be used to subscribe to > that user in the case of a buddy list subscription. If you had > additional information about that user, for example, a pres URI, IM URI, > or tel URI, you would include those as informational elements within the > entry. So: > > > im:user@example.com > tel:+17325551212 > Joe User > > > What I want to make sure of, is that the basic case which we are most > concerned about (a single URI, used for list subscriptions), works well > and efficiently, including the ad-hoc case. > > Thanks, > Jonathan R. -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 09:38:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28765 for ; Thu, 17 Jun 2004 09:38:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bax5i-0002Pa-5g for simple-archive@ietf.org; Thu, 17 Jun 2004 09:38:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bax4U-00022Y-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 09:36:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bax3v-0001hk-00; Thu, 17 Jun 2004 09:36:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bawxv-0002V1-Kq; Thu, 17 Jun 2004 09:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bawk0-0002CB-54; Thu, 17 Jun 2004 09:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bawe8-0000Xo-4G for simple@megatron.ietf.org; Thu, 17 Jun 2004 09:09: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 JAA27368 for ; Thu, 17 Jun 2004 09:09:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bawe7-0001RK-Jn for simple@ietf.org; Thu, 17 Jun 2004 09:09:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bawd1-00011l-00 for simple@ietf.org; Thu, 17 Jun 2004 09:08:28 -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 1BawbC-00001w-00 for simple@ietf.org; Thu, 17 Jun 2004 09:06:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2004 06:08:38 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5HD61Sx006294; Thu, 17 Jun 2004 06:06:01 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJM34463; Thu, 17 Jun 2004 09:06:00 -0400 (EDT) Message-ID: <40D19738.9000401@cisco.com> Date: Thu, 17 Jun 2004 09:06:00 -0400 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 Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <2038BCC78B1AD641891A0D1AE133DBB701797C84@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I don't feel strongly about this, so I won't argue very hard. As described, I found the interaction between the flags and the mechanisms of when to send reports and when to send responses to be quite obscure. Adding another flag is one way to resolve that. Potentially it could also be resolved by the way things are named and described. In any case, the end result is quite pleasing, though it offers options that it would seemingly be insane to use. Paul hisham.khartabil@nokia.com wrote: > I don't like the idea of having a 3rd flag. The flags are clearly for the sender to indicate the desire to receive DSNs or not. The transactional responses are a consequence of that choice. We should not mix that with transactional response flags. Also I don't believe it is a good idea to give the sender the ability to control when responses are sent, especially when they are useless and don't give any extra information to the sender nor to the relays, but instead cause useless traffic to flow in the network. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Paul Kyzivat >>Sent: 17.June.2004 03:07 >>To: Mike Hammer >>Cc: Ben Campbell; Simple WG >>Subject: Re: [Simple] MSRP: delivery reports and transaction responses >> >> >>When I read the proposal I had a similar reaction to what Mike had. I >>was going to comment but decided it was good enough so I >>would leave it >>be. But since Mike was troubled by the same thing I will support him: >> >>It would be clearer if there were three flags rather than >>two, with the >>the third explicitly controlling the sending of responses. This does >>permit some nonsense combinations, but they can be simply declared >>illegal. (And if anyone uses a nonsense combination they will >>get what >>they deserve.) And with three flags, they would all be binary. >> >> Paul >> >>Mike Hammer wrote: >> >>>The use of the terms sender and recipient could be >> >>endpoints or relays, >> >>>depending on whether you are talking hop-by-hop or >> >>end-to-end. So, I am >> >>>a bit fuzzy until some more precise language is provided. >> >>Otherwise, I >> >>>am guessing as to exactly what you intended. Your fist paragraph >>>indicates that reports are endpoint only, and thus omits >> >>any discussion >> >>>of relays. But, then the report failure flag includes >> >>relay behavior >> >>>reactions. Thus, my uncertainty and guessing. >>> >>>However, either way, the overall behavior could be the same >> >>using three >> >>>flags instead of two. The suggestions were to help confirm >> >>for myself >> >>>that I had read your intent correctly. >>> >>>Mike >>> >>> >>>At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: >>> >>> >>>>First, just to make sure things are clear, this was not >>> >>proposed draft >> >>>>verbiage, it was just a quick descripiton of the approach. >>> >>Not only >> >>>>will the draft language be more precise, we will be splitting the >>>>endpoint vs. relay behavior between the appropriate drafts. >>>> >>>>Further comments inline: >>>> >>>>Mike Hammer wrote: >>>> >>>> >>>>>Ben, >>>>>It seems like you could simplify things further if you >>>> >>de-coupled the >> >>>>>reports from the responses described in your last 4 paragraphs. >>>> >>>> >>>>Do you mean decouple the behavior, or decouple the >>> >>descriptions? If >> >>>>the first, please let me know what you have in mind. >>>> >>>>This >>>> >>>> >>>>>would also help support the clarity you seek in the first >>>> >>paragraph >> >>>>>and enable some symmetry in having only binary flags. (Having a >>>>>'tricky' part is the first clue to complexity.) >>>>>It would also help if you define the behavior upon >>>> >>receiving the SEND >> >>>>>with each flag for each device type (senders, endpoints, relays, >>>>>gateways, recipients -- a non-redundant set would help >>>> >>readability). >> >>>>>Lumping two flags or device types in one sentence makes >>>> >>parsing more >> >>>>>difficult. >>>> >>>> >>>>The drafts will do that. >>>> >>>> >>>>>Mike >>>>> >>>>>At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >>>>> >>>>> >>>>>>In Boston, we had a proposal for a comprimise solution >>>>> >>on handling >> >>>>>>delivery reports and transaction responses. The primary >>>>> >>contributors >> >>>>>>have had a number of discussions, and came up with some details. >>>>>>This does not address questions of DSN format, nor does it talk >>>>>>about DSN reports that occur after a session has >>>>> >>ended--those will >> >>>>>>be shortly forthcoming. This note only addresses when to >>>>> >>send DSN >> >>>>>>reports and transaction responses, and the relationship >>>>> >>between them. >> >>>>>>----------------------- >>>>>> >>>>>>First, a clarification of terms. When we use the term "delivery >>>>>>report" (or "reports" for short), we mean a report sent >>>>> >>back to the >> >>>>>>sender to tell it the delivery status. This is different than >>>>>>"transaction responses" (or "responses" for short). Transaction >>>>>>responses to SEND requests are strictly hop-by-hop, >>>>> >>while delivery >> >>>>>>reports are generally end-to-end, or middle-to-end if >>>>> >>the reporting >> >>>>>>device is a relay. >>>>>> >>>>>>The sender requests delivery reports on a message by >>>>> >>message basis. >> >>>>>>This is done in an MSRP header in a SEND request. That >>>>> >>header has >> >>>>>>two distinct flags. One indicates the desire to get >>>>> >>failure reports, >> >>>>>>and the other indicates the desire to get success reports. The >>>>>>sender can set any combination of these flags. >>>>>> >>>>>>The success report request flag can have values of true >>>>> >>or false. If >> >>>>>>the flag is true, then the receiving endpoint MUST send back a >>>>>>success report when it successfully receives a message. >>>>> >>This does >> >>>>>>not say anything about the message disposition after >>>>> >>reception, only >> >>>>>>that is was successfully received. If this flag is false, the >>>>>>receiving endpoint MUST NOT send success reports. >>>>> >>Success reports >> >>>>>>are strictly end-to-end, that is, Relays _never_ send >>>>> >>success reports. >> >>>>>>The failure report request flag can have three values: >>>>> >>True, False, >> >>>>>>and "partial". If this flag is false, then both the receiving >>>>>>endpoint and any relays MUST NOT send failure reports. If it is >>>>>>"partial", then the receiving device and any relay >>>>> >>SHOULD send an >> >>>>>>error report if it detects a "fatal" error; that is, an >>>>> >>error which >> >>>>>>prevents delivery of the message. >>>>>> >>>>>>Now, here is the tricky part: None of the conditions >>>>> >>described so >> >>>>>>far involve the use of transaction responses to SEND >>>>> >>requests. If >> >>>>>>the failure report request flag is any value other than >>>>> >>True, then >> >>>>>>MSRP devices SHOULD NOT send transaction responses for >>>>> >>the request. >> >>>>>>Furthermore, devices MUST NOT "expect" transaction responses, >>>>>>although they should not freak out if they get one. >>>>>> >>>>>>If the failure report request flag is True, then the >>>>> >>recipient, and >> >>>>>>any relays, MUST send send a transaction response. If any device >>>>>>detects an error which prevents delivery, it SHOULD send >>>>> >>a failure >> >>>>>>transaction response back to the previous hop. If it is >>>>> >>unable to >> >>>>>>immediately detect the error, it MAY send a 200 OK response, >>>>>>followed by a failure _report_ when the error is >>>>> >>detected. (This is >> >>>>>>mainly for gateway devices, which may not notice the error until >>>>>>they are informed by the downstream network.) >>>>>> >>>>>>If any relay receives a failure transaction response to a SEND >>>>>>request where failure reports are requested, that device >>>>> >>MUST send a >> >>>>>>failure report. If the sending device receives a failure >>>>> >>transaction >> >>>>>>response, it acts the same as if it had received a >>>>> >>failure report >> >>>>>>with the same information. Furthermore, if any such device >>>>>>determines that delivery to the next hop has failed >>>>> >>because either a >> >>>>>>transport error or a locally defined timeout period has expired >>>>>>before receiving a 200 OK response, it MUST act as if it had >>>>>>received an appropriate error response. >>>>>> >>>>>>_______________________________________________ >>>>>>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-bounces@ietf.org Thu Jun 17 10:38:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05511 for ; Thu, 17 Jun 2004 10:38:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bay22-0004mS-86 for simple-archive@ietf.org; Thu, 17 Jun 2004 10:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaxyH-0003to-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 10:34:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Baxua-0002mN-00; Thu, 17 Jun 2004 10:30:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaxdG-0007SH-9V; Thu, 17 Jun 2004 10:12:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaxIn-00037i-SI for simple@megatron.ietf.org; Thu, 17 Jun 2004 09:51: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 JAA29483 for ; Thu, 17 Jun 2004 09:51:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaxIn-00075L-5r for simple@ietf.org; Thu, 17 Jun 2004 09:51:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaxHt-0006l1-00 for simple@ietf.org; Thu, 17 Jun 2004 09:50:42 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BaxH6-0006Qj-00 for simple@ietf.org; Thu, 17 Jun 2004 09:49:52 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7079189 for simple@ietf.org; Thu, 17 Jun 2004 09:49:49 -0400 Message-Id: <5.1.0.14.0.20040617094705.02312ea8@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Jun 2004 09:49:29 -0400 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] XCAP Issue 4 Interim Summary: document to element separator In-Reply-To: <40D177E4.3070402@dynamicsoft.com> References: <1086872390.7949.36.camel@xitami.research.nokia.com> <40C7FC2A.5080405@dynamicsoft.com> <1086872390.7949.36.camel@xitami.research.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 To rephrase my concern slightly, I am not particularly concerned about transparent (or other) proxies in the communication path rewriting the ~ to be the users home directory. I am concerned about the case where the HTTP processing logic in the target, before it hands to URI off to the XCAP logic, may replace the ~ with the users home directory. I am not sure how likely that is. It seems extremely unlikely that such logic would replace ~~ with anything. Aesthetically, I prefer a single ~. For safety, I am inclined towards the double. Yours, Joel At 06:52 AM 6/17/2004 -0400, Jonathan Rosenberg wrote: >We need to keep in mind that XCAP is all about defining the structure of a >URI and defining the resource it identifies. Thus, its not like you are >going to see arbitrary URIs. We can simply mandate that no path in the >directory have the name "~~". The concern was around the possibility of >transparent proxies and other nasties that would not know about xcap, and >would rewrite the "~" in a URI to the home directory of a user. This idea >was that they wouldn't rewrite a "~~". > >If we don't worry about that case (transparent proxies rewriting URIs), >then we can even use the "~" safely, just by mandating that the XCAP >server never allow "~" as a part of the path. > >Honestly, I'd rather do that and just use the single tilde. > >-Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 10:42:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06045 for ; Thu, 17 Jun 2004 10:42:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bay69-0006kH-Md for simple-archive@ietf.org; Thu, 17 Jun 2004 10:42:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bay5A-0006NR-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 10:41:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bay47-0005az-00; Thu, 17 Jun 2004 10:40:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaxyU-0007b0-6h; Thu, 17 Jun 2004 10:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZxFl-0001cG-8r for simple@megatron.ietf.org; Mon, 14 Jun 2004 15:36: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 PAA23882 for ; Mon, 14 Jun 2004 15:36:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZxFk-0006I6-0C for simple@ietf.org; Mon, 14 Jun 2004 15:36:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZxEl-00060G-00 for simple@ietf.org; Mon, 14 Jun 2004 15:35:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZxDr-0005QJ-00; Mon, 14 Jun 2004 15:34:23 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BZxAx-0000f9-NM; Mon, 14 Jun 2004 15:31:23 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 14 Jun 2004 15:31:23 -0400 X-Mailman-Approved-At: Thu, 17 Jun 2004 10:34:40 -0400 Cc: simple@ietf.org Subject: [Simple] Last Call: 'Indication of Message Composition for Instant Messaging' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'Indication of Message Composition for Instant Messaging ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-06-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-02.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 11:06:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08169 for ; Thu, 17 Jun 2004 11:06:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BayTV-0006jm-Mf for simple-archive@ietf.org; Thu, 17 Jun 2004 11:06:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaySD-00066U-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 11:05:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BayPJ-0005EO-00; Thu, 17 Jun 2004 11:02:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BayIh-0005gW-79; Thu, 17 Jun 2004 10:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bay2t-0000kF-7j for simple@megatron.ietf.org; Thu, 17 Jun 2004 10:39: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 KAA05599 for ; Thu, 17 Jun 2004 10:39:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bay2s-0005BM-FU for simple@ietf.org; Thu, 17 Jun 2004 10:39:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bay04-0004Du-00 for simple@ietf.org; Thu, 17 Jun 2004 10:36:21 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BaxvP-0002um-00 for simple@ietf.org; Thu, 17 Jun 2004 10:31:31 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2004 10:36:32 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5HEUwhD021520; Thu, 17 Jun 2004 10:30:59 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA04187; Thu, 17 Jun 2004 07:30:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617102412.00b0c280@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 10:31:49 -0400 To: "Chris Boulton" , , From: Mike Hammer Subject: RE: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF4AA@gbnewp0758m.eu.ub iquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Chris, If the extra indication is not needed, then there would be no need for three states in the flag that affects both reports and responses. As Paul suggested, it depends on how you name the third flag and define its usage. I think if you would define the success and failure flags strictly in terms of how and when reports are sent or suppressed, then ask what is missing, you would likely find that the final ingredient is to suppress or encourage transaction responses by a particular device type at some points in the flow. You could then define that 3rd flag to do that more specific function. That should be a rather simple exercise to try, so why not do it? Mike At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote: >I'm with Hisham on this - I think a third flag would just confuse the >process. It has been identified that transaction responses are only >really needed in one DSN request state (negative=true) - why have a >third flag to convey this? > >Chris. > > > > > >I don't like the idea of having a 3rd flag. The flags are clearly for >the > >sender to indicate the desire to receive DSNs or not. The transactional > >responses are a consequence of that choice. We should not mix that with > >transactional response flags. Also I don't believe it is a good idea to > >give the sender the ability to control when responses are sent, >especially > >when they are useless and don't give any extra information to the >sender > >nor to the relays, but instead cause useless traffic to flow in the > >network. > > > >Regards, > >Hisham > > > >> -----Original Message----- > >> From: simple-bounces@ietf.org > >> [mailto:simple-bounces@ietf.org]On Behalf > >> Of ext Paul Kyzivat > >> Sent: 17.June.2004 03:07 > >> To: Mike Hammer > >> Cc: Ben Campbell; Simple WG > >> Subject: Re: [Simple] MSRP: delivery reports and transaction >responses > >> > >> > >> When I read the proposal I had a similar reaction to what Mike had. I > >> was going to comment but decided it was good enough so I > >> would leave it > >> be. But since Mike was troubled by the same thing I will support him: > >> > >> It would be clearer if there were three flags rather than > >> two, with the > >> the third explicitly controlling the sending of responses. This does > >> permit some nonsense combinations, but they can be simply declared > >> illegal. (And if anyone uses a nonsense combination they will > >> get what > >> they deserve.) And with three flags, they would all be binary. > >> > >> Paul > >> > >> Mike Hammer wrote: > >> > The use of the terms sender and recipient could be > >> endpoints or relays, > >> > depending on whether you are talking hop-by-hop or > >> end-to-end. So, I am > >> > a bit fuzzy until some more precise language is provided. > >> Otherwise, I > >> > am guessing as to exactly what you intended. Your fist paragraph > >> > indicates that reports are endpoint only, and thus omits > >> any discussion > >> > of relays. But, then the report failure flag includes > >> relay behavior > >> > reactions. Thus, my uncertainty and guessing. > >> > > >> > However, either way, the overall behavior could be the same > >> using three > >> > flags instead of two. The suggestions were to help confirm > >> for myself > >> > that I had read your intent correctly. > >> > > >> > Mike > >> > > >> > > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: > >> > > >> >> First, just to make sure things are clear, this was not > >> proposed draft > >> >> verbiage, it was just a quick descripiton of the approach. > >> Not only > >> >> will the draft language be more precise, we will be splitting the > >> >> endpoint vs. relay behavior between the appropriate drafts. > >> >> > >> >> Further comments inline: > >> >> > >> >> Mike Hammer wrote: > >> >> > >> >>> Ben, > >> >>> It seems like you could simplify things further if you > >> de-coupled the > >> >>> reports from the responses described in your last 4 paragraphs. > >> >> > >> >> > >> >> Do you mean decouple the behavior, or decouple the > >> descriptions? If > >> >> the first, please let me know what you have in mind. > >> >> > >> >> This > >> >> > >> >>> would also help support the clarity you seek in the first > >> paragraph > >> >>> and enable some symmetry in having only binary flags. (Having a > >> >>> 'tricky' part is the first clue to complexity.) > >> >>> It would also help if you define the behavior upon > >> receiving the SEND > >> >>> with each flag for each device type (senders, endpoints, relays, > >> >>> gateways, recipients -- a non-redundant set would help > >> readability). > >> >>> Lumping two flags or device types in one sentence makes > >> parsing more > >> >>> difficult. > >> >> > >> >> > >> >> The drafts will do that. > >> >> > >> >>> Mike > >> >>> > >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: > >> >>> > >> >>>> In Boston, we had a proposal for a comprimise solution > >> on handling > >> >>>> delivery reports and transaction responses. The primary > >> contributors > >> >>>> have had a number of discussions, and came up with some details. > >> >>>> This does not address questions of DSN format, nor does it talk > >> >>>> about DSN reports that occur after a session has > >> ended--those will > >> >>>> be shortly forthcoming. This note only addresses when to > >> send DSN > >> >>>> reports and transaction responses, and the relationship > >> between them. > >> >>>> > >> >>>> ----------------------- > >> >>>> > >> >>>> First, a clarification of terms. When we use the term "delivery > >> >>>> report" (or "reports" for short), we mean a report sent > >> back to the > >> >>>> sender to tell it the delivery status. This is different than > >> >>>> "transaction responses" (or "responses" for short). Transaction > >> >>>> responses to SEND requests are strictly hop-by-hop, > >> while delivery > >> >>>> reports are generally end-to-end, or middle-to-end if > >> the reporting > >> >>>> device is a relay. > >> >>>> > >> >>>> The sender requests delivery reports on a message by > >> message basis. > >> >>>> This is done in an MSRP header in a SEND request. That > >> header has > >> >>>> two distinct flags. One indicates the desire to get > >> failure reports, > >> >>>> and the other indicates the desire to get success reports. The > >> >>>> sender can set any combination of these flags. > >> >>>> > >> >>>> The success report request flag can have values of true > >> or false. If > >> >>>> the flag is true, then the receiving endpoint MUST send back a > >> >>>> success report when it successfully receives a message. > >> This does > >> >>>> not say anything about the message disposition after > >> reception, only > >> >>>> that is was successfully received. If this flag is false, the > >> >>>> receiving endpoint MUST NOT send success reports. > >> Success reports > >> >>>> are strictly end-to-end, that is, Relays _never_ send > >> success reports. > >> >>>> > >> >>>> The failure report request flag can have three values: > >> True, False, > >> >>>> and "partial". If this flag is false, then both the receiving > >> >>>> endpoint and any relays MUST NOT send failure reports. If it is > >> >>>> "partial", then the receiving device and any relay > >> SHOULD send an > >> >>>> error report if it detects a "fatal" error; that is, an > >> error which > >> >>>> prevents delivery of the message. > >> >>>> > >> >>>> Now, here is the tricky part: None of the conditions > >> described so > >> >>>> far involve the use of transaction responses to SEND > >> requests. If > >> >>>> the failure report request flag is any value other than > >> True, then > >> >>>> MSRP devices SHOULD NOT send transaction responses for > >> the request. > >> >>>> Furthermore, devices MUST NOT "expect" transaction responses, > >> >>>> although they should not freak out if they get one. > >> >>>> > >> >>>> If the failure report request flag is True, then the > >> recipient, and > >> >>>> any relays, MUST send send a transaction response. If any device > >> >>>> detects an error which prevents delivery, it SHOULD send > >> a failure > >> >>>> transaction response back to the previous hop. If it is > >> unable to > >> >>>> immediately detect the error, it MAY send a 200 OK response, > >> >>>> followed by a failure _report_ when the error is > >> detected. (This is > >> >>>> mainly for gateway devices, which may not notice the error until > >> >>>> they are informed by the downstream network.) > >> >>>> > >> >>>> If any relay receives a failure transaction response to a SEND > >> >>>> request where failure reports are requested, that device > >> MUST send a > >> >>>> failure report. If the sending device receives a failure > >> transaction > >> >>>> response, it acts the same as if it had received a > >> failure report > >> >>>> with the same information. Furthermore, if any such device > >> >>>> determines that delivery to the next hop has failed > >> because either a > >> >>>> transport error or a locally defined timeout period has expired > >> >>>> before receiving a 200 OK response, it MUST act as if it had > >> >>>> received an appropriate error response. > >> >>>> > >> >>>> _______________________________________________ > >> >>>> 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 > > >This message has been scanned for viruses by MailControl - >www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 11:07:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08389 for ; Thu, 17 Jun 2004 11:07:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BayUh-00079i-Jl for simple-archive@ietf.org; Thu, 17 Jun 2004 11:07:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BayU4-0006ni-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 11:07:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BaySx-0006He-00; Thu, 17 Jun 2004 11:06:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BayIk-0005jK-J9; Thu, 17 Jun 2004 10:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bay3R-0000pp-Af for simple@megatron.ietf.org; Thu, 17 Jun 2004 10:39: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 KAA05715 for ; Thu, 17 Jun 2004 10:39:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bay3Q-0005YE-FV for simple@ietf.org; Thu, 17 Jun 2004 10:39:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bay0z-0004dV-00 for simple@ietf.org; Thu, 17 Jun 2004 10:37:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Baxwq-0003SJ-00 for simple@ietf.org; Thu, 17 Jun 2004 10:33:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2004 10:38:01 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5HEWR4w007593; Thu, 17 Jun 2004 10:32:28 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA04301; Thu, 17 Jun 2004 07:32:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617103234.00b0c8b0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 10:33:18 -0400 To: "Chris Boulton" , , From: Mike Hammer Subject: RE: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF4AA@gbnewp0758m.eu.ub iquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 p.s. The "why" is that the process as currently stated is already confusing, except to those who know what they intended to convey. Mike At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote: >I'm with Hisham on this - I think a third flag would just confuse the >process. It has been identified that transaction responses are only >really needed in one DSN request state (negative=true) - why have a >third flag to convey this? > >Chris. > > > > > >I don't like the idea of having a 3rd flag. The flags are clearly for >the > >sender to indicate the desire to receive DSNs or not. The transactional > >responses are a consequence of that choice. We should not mix that with > >transactional response flags. Also I don't believe it is a good idea to > >give the sender the ability to control when responses are sent, >especially > >when they are useless and don't give any extra information to the >sender > >nor to the relays, but instead cause useless traffic to flow in the > >network. > > > >Regards, > >Hisham > > > >> -----Original Message----- > >> From: simple-bounces@ietf.org > >> [mailto:simple-bounces@ietf.org]On Behalf > >> Of ext Paul Kyzivat > >> Sent: 17.June.2004 03:07 > >> To: Mike Hammer > >> Cc: Ben Campbell; Simple WG > >> Subject: Re: [Simple] MSRP: delivery reports and transaction >responses > >> > >> > >> When I read the proposal I had a similar reaction to what Mike had. I > >> was going to comment but decided it was good enough so I > >> would leave it > >> be. But since Mike was troubled by the same thing I will support him: > >> > >> It would be clearer if there were three flags rather than > >> two, with the > >> the third explicitly controlling the sending of responses. This does > >> permit some nonsense combinations, but they can be simply declared > >> illegal. (And if anyone uses a nonsense combination they will > >> get what > >> they deserve.) And with three flags, they would all be binary. > >> > >> Paul > >> > >> Mike Hammer wrote: > >> > The use of the terms sender and recipient could be > >> endpoints or relays, > >> > depending on whether you are talking hop-by-hop or > >> end-to-end. So, I am > >> > a bit fuzzy until some more precise language is provided. > >> Otherwise, I > >> > am guessing as to exactly what you intended. Your fist paragraph > >> > indicates that reports are endpoint only, and thus omits > >> any discussion > >> > of relays. But, then the report failure flag includes > >> relay behavior > >> > reactions. Thus, my uncertainty and guessing. > >> > > >> > However, either way, the overall behavior could be the same > >> using three > >> > flags instead of two. The suggestions were to help confirm > >> for myself > >> > that I had read your intent correctly. > >> > > >> > Mike > >> > > >> > > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: > >> > > >> >> First, just to make sure things are clear, this was not > >> proposed draft > >> >> verbiage, it was just a quick descripiton of the approach. > >> Not only > >> >> will the draft language be more precise, we will be splitting the > >> >> endpoint vs. relay behavior between the appropriate drafts. > >> >> > >> >> Further comments inline: > >> >> > >> >> Mike Hammer wrote: > >> >> > >> >>> Ben, > >> >>> It seems like you could simplify things further if you > >> de-coupled the > >> >>> reports from the responses described in your last 4 paragraphs. > >> >> > >> >> > >> >> Do you mean decouple the behavior, or decouple the > >> descriptions? If > >> >> the first, please let me know what you have in mind. > >> >> > >> >> This > >> >> > >> >>> would also help support the clarity you seek in the first > >> paragraph > >> >>> and enable some symmetry in having only binary flags. (Having a > >> >>> 'tricky' part is the first clue to complexity.) > >> >>> It would also help if you define the behavior upon > >> receiving the SEND > >> >>> with each flag for each device type (senders, endpoints, relays, > >> >>> gateways, recipients -- a non-redundant set would help > >> readability). > >> >>> Lumping two flags or device types in one sentence makes > >> parsing more > >> >>> difficult. > >> >> > >> >> > >> >> The drafts will do that. > >> >> > >> >>> Mike > >> >>> > >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: > >> >>> > >> >>>> In Boston, we had a proposal for a comprimise solution > >> on handling > >> >>>> delivery reports and transaction responses. The primary > >> contributors > >> >>>> have had a number of discussions, and came up with some details. > >> >>>> This does not address questions of DSN format, nor does it talk > >> >>>> about DSN reports that occur after a session has > >> ended--those will > >> >>>> be shortly forthcoming. This note only addresses when to > >> send DSN > >> >>>> reports and transaction responses, and the relationship > >> between them. > >> >>>> > >> >>>> ----------------------- > >> >>>> > >> >>>> First, a clarification of terms. When we use the term "delivery > >> >>>> report" (or "reports" for short), we mean a report sent > >> back to the > >> >>>> sender to tell it the delivery status. This is different than > >> >>>> "transaction responses" (or "responses" for short). Transaction > >> >>>> responses to SEND requests are strictly hop-by-hop, > >> while delivery > >> >>>> reports are generally end-to-end, or middle-to-end if > >> the reporting > >> >>>> device is a relay. > >> >>>> > >> >>>> The sender requests delivery reports on a message by > >> message basis. > >> >>>> This is done in an MSRP header in a SEND request. That > >> header has > >> >>>> two distinct flags. One indicates the desire to get > >> failure reports, > >> >>>> and the other indicates the desire to get success reports. The > >> >>>> sender can set any combination of these flags. > >> >>>> > >> >>>> The success report request flag can have values of true > >> or false. If > >> >>>> the flag is true, then the receiving endpoint MUST send back a > >> >>>> success report when it successfully receives a message. > >> This does > >> >>>> not say anything about the message disposition after > >> reception, only > >> >>>> that is was successfully received. If this flag is false, the > >> >>>> receiving endpoint MUST NOT send success reports. > >> Success reports > >> >>>> are strictly end-to-end, that is, Relays _never_ send > >> success reports. > >> >>>> > >> >>>> The failure report request flag can have three values: > >> True, False, > >> >>>> and "partial". If this flag is false, then both the receiving > >> >>>> endpoint and any relays MUST NOT send failure reports. If it is > >> >>>> "partial", then the receiving device and any relay > >> SHOULD send an > >> >>>> error report if it detects a "fatal" error; that is, an > >> error which > >> >>>> prevents delivery of the message. > >> >>>> > >> >>>> Now, here is the tricky part: None of the conditions > >> described so > >> >>>> far involve the use of transaction responses to SEND > >> requests. If > >> >>>> the failure report request flag is any value other than > >> True, then > >> >>>> MSRP devices SHOULD NOT send transaction responses for > >> the request. > >> >>>> Furthermore, devices MUST NOT "expect" transaction responses, > >> >>>> although they should not freak out if they get one. > >> >>>> > >> >>>> If the failure report request flag is True, then the > >> recipient, and > >> >>>> any relays, MUST send send a transaction response. If any device > >> >>>> detects an error which prevents delivery, it SHOULD send > >> a failure > >> >>>> transaction response back to the previous hop. If it is > >> unable to > >> >>>> immediately detect the error, it MAY send a 200 OK response, > >> >>>> followed by a failure _report_ when the error is > >> detected. (This is > >> >>>> mainly for gateway devices, which may not notice the error until > >> >>>> they are informed by the downstream network.) > >> >>>> > >> >>>> If any relay receives a failure transaction response to a SEND > >> >>>> request where failure reports are requested, that device > >> MUST send a > >> >>>> failure report. If the sending device receives a failure > >> transaction > >> >>>> response, it acts the same as if it had received a > >> failure report > >> >>>> with the same information. Furthermore, if any such device > >> >>>> determines that delivery to the next hop has failed > >> because either a > >> >>>> transport error or a locally defined timeout period has expired > >> >>>> before receiving a 200 OK response, it MUST act as if it had > >> >>>> received an appropriate error response. > >> >>>> > >> >>>> _______________________________________________ > >> >>>> 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 > > >This message has been scanned for viruses by MailControl - >www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 12:36:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17394 for ; Thu, 17 Jun 2004 12:36:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BazsK-0002VM-Pi for simple-archive@ietf.org; Thu, 17 Jun 2004 12:36:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BazkJ-0000g3-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 12:28:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BazfB-0006wv-00; Thu, 17 Jun 2004 12:22:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BazQA-0002ON-4e; Thu, 17 Jun 2004 12:07:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bayif-0004fW-LY; Thu, 17 Jun 2004 11:22:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baye5-0002x1-01 for simple@megatron.ietf.org; Thu, 17 Jun 2004 11:17: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 LAA09179 for ; Thu, 17 Jun 2004 11:17:38 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Baye4-0002nY-6V for simple@ietf.org; Thu, 17 Jun 2004 11:17:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bayd5-0002Rk-00 for simple@ietf.org; Thu, 17 Jun 2004 11:16:40 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BaycM-00027C-00 for simple@ietf.org; Thu, 17 Jun 2004 11:15:54 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5HFEj612398; Thu, 17 Jun 2004 18:14:45 +0300 (EET DST) X-Scanned: Thu, 17 Jun 2004 18:14:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5HFET8H019437; Thu, 17 Jun 2004 18:14:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 003aieID; Thu, 17 Jun 2004 18:14:28 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5HFESH07553; Thu, 17 Jun 2004 18:14:28 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Jun 2004 18:14: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: delivery reports and transaction responses Date: Thu, 17 Jun 2004 18:14:28 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C8B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: delivery reports and transaction responses Thread-Index: AcRUfAbOHu0irUqdR3uEKMS3Ih/3EAAAS/KA To: , , X-OriginalArrivalTime: 17 Jun 2004 15:14:29.0197 (UTC) FILETIME=[C8EF07D0:01C4547D] Content-Transfer-Encoding: quoted-printable Cc: bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I don't understand what is so complicated about this (perhaps Ben = complicated the text too much. You might feel better when you see the = text that will be in the draft). The guts of the proposal is: No = responses are sent to SEND requests unless a negative DSN is requested = by the sender. Regards, Hisham > -----Original Message----- > From: ext Mike Hammer [mailto:mhammer@cisco.com] > Sent: 17.June.2004 17:32 > To: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > pkyzivat@cisco.com > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] MSRP: delivery reports and transaction responses >=20 >=20 > Chris, >=20 > If the extra indication is not needed, then there would be no=20 > need for=20 > three states in the flag that affects both reports and=20 > responses. As Paul=20 > suggested, it depends on how you name the third flag and=20 > define its usage. >=20 > I think if you would define the success and failure flags=20 > strictly in terms=20 > of how and when reports are sent or suppressed, then ask what=20 > is missing,=20 > you would likely find that the final ingredient is to=20 > suppress or encourage=20 > transaction responses by a particular device type at some=20 > points in the=20 > flow. You could then define that 3rd flag to do that more specific=20 > function. That should be a rather simple exercise to try, so=20 > why not do it? >=20 > Mike >=20 >=20 > At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote: > >I'm with Hisham on this - I think a third flag would just confuse the > >process. It has been identified that transaction responses are only > >really needed in one DSN request state (negative=3Dtrue) - why have a > >third flag to convey this? > > > >Chris. > > > > > > > > > >I don't like the idea of having a 3rd flag. The flags are=20 > clearly for > >the > > >sender to indicate the desire to receive DSNs or not. The=20 > transactional > > >responses are a consequence of that choice. We should not=20 > mix that with > > >transactional response flags. Also I don't believe it is a=20 > good idea to > > >give the sender the ability to control when responses are sent, > >especially > > >when they are useless and don't give any extra information to the > >sender > > >nor to the relays, but instead cause useless traffic to flow in the > > >network. > > > > > >Regards, > > >Hisham > > > > > >> -----Original Message----- > > >> From: simple-bounces@ietf.org > > >> [mailto:simple-bounces@ietf.org]On Behalf > > >> Of ext Paul Kyzivat > > >> Sent: 17.June.2004 03:07 > > >> To: Mike Hammer > > >> Cc: Ben Campbell; Simple WG > > >> Subject: Re: [Simple] MSRP: delivery reports and transaction > >responses > > >> > > >> > > >> When I read the proposal I had a similar reaction to=20 > what Mike had. I > > >> was going to comment but decided it was good enough so I > > >> would leave it > > >> be. But since Mike was troubled by the same thing I will=20 > support him: > > >> > > >> It would be clearer if there were three flags rather than > > >> two, with the > > >> the third explicitly controlling the sending of=20 > responses. This does > > >> permit some nonsense combinations, but they can be=20 > simply declared > > >> illegal. (And if anyone uses a nonsense combination they will > > >> get what > > >> they deserve.) And with three flags, they would all be binary. > > >> > > >> Paul > > >> > > >> Mike Hammer wrote: > > >> > The use of the terms sender and recipient could be > > >> endpoints or relays, > > >> > depending on whether you are talking hop-by-hop or > > >> end-to-end. So, I am > > >> > a bit fuzzy until some more precise language is provided. > > >> Otherwise, I > > >> > am guessing as to exactly what you intended. Your=20 > fist paragraph > > >> > indicates that reports are endpoint only, and thus omits > > >> any discussion > > >> > of relays. But, then the report failure flag includes > > >> relay behavior > > >> > reactions. Thus, my uncertainty and guessing. > > >> > > > >> > However, either way, the overall behavior could be the same > > >> using three > > >> > flags instead of two. The suggestions were to help confirm > > >> for myself > > >> > that I had read your intent correctly. > > >> > > > >> > Mike > > >> > > > >> > > > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: > > >> > > > >> >> First, just to make sure things are clear, this was not > > >> proposed draft > > >> >> verbiage, it was just a quick descripiton of the approach. > > >> Not only > > >> >> will the draft language be more precise, we will be=20 > splitting the > > >> >> endpoint vs. relay behavior between the appropriate drafts. > > >> >> > > >> >> Further comments inline: > > >> >> > > >> >> Mike Hammer wrote: > > >> >> > > >> >>> Ben, > > >> >>> It seems like you could simplify things further if you > > >> de-coupled the > > >> >>> reports from the responses described in your last 4=20 > paragraphs. > > >> >> > > >> >> > > >> >> Do you mean decouple the behavior, or decouple the > > >> descriptions? If > > >> >> the first, please let me know what you have in mind. > > >> >> > > >> >> This > > >> >> > > >> >>> would also help support the clarity you seek in the first > > >> paragraph > > >> >>> and enable some symmetry in having only binary=20 > flags. (Having a > > >> >>> 'tricky' part is the first clue to complexity.) > > >> >>> It would also help if you define the behavior upon > > >> receiving the SEND > > >> >>> with each flag for each device type (senders,=20 > endpoints, relays, > > >> >>> gateways, recipients -- a non-redundant set would help > > >> readability). > > >> >>> Lumping two flags or device types in one sentence makes > > >> parsing more > > >> >>> difficult. > > >> >> > > >> >> > > >> >> The drafts will do that. > > >> >> > > >> >>> Mike > > >> >>> > > >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: > > >> >>> > > >> >>>> In Boston, we had a proposal for a comprimise solution > > >> on handling > > >> >>>> delivery reports and transaction responses. The primary > > >> contributors > > >> >>>> have had a number of discussions, and came up with=20 > some details. > > >> >>>> This does not address questions of DSN format, nor=20 > does it talk > > >> >>>> about DSN reports that occur after a session has > > >> ended--those will > > >> >>>> be shortly forthcoming. This note only addresses when to > > >> send DSN > > >> >>>> reports and transaction responses, and the relationship > > >> between them. > > >> >>>> > > >> >>>> ----------------------- > > >> >>>> > > >> >>>> First, a clarification of terms. When we use the=20 > term "delivery > > >> >>>> report" (or "reports" for short), we mean a report sent > > >> back to the > > >> >>>> sender to tell it the delivery status. This is=20 > different than > > >> >>>> "transaction responses" (or "responses" for short).=20 > Transaction > > >> >>>> responses to SEND requests are strictly hop-by-hop, > > >> while delivery > > >> >>>> reports are generally end-to-end, or middle-to-end if > > >> the reporting > > >> >>>> device is a relay. > > >> >>>> > > >> >>>> The sender requests delivery reports on a message by > > >> message basis. > > >> >>>> This is done in an MSRP header in a SEND request. That > > >> header has > > >> >>>> two distinct flags. One indicates the desire to get > > >> failure reports, > > >> >>>> and the other indicates the desire to get success=20 > reports. The > > >> >>>> sender can set any combination of these flags. > > >> >>>> > > >> >>>> The success report request flag can have values of true > > >> or false. If > > >> >>>> the flag is true, then the receiving endpoint MUST=20 > send back a > > >> >>>> success report when it successfully receives a message. > > >> This does > > >> >>>> not say anything about the message disposition after > > >> reception, only > > >> >>>> that is was successfully received. If this flag is=20 > false, the > > >> >>>> receiving endpoint MUST NOT send success reports. > > >> Success reports > > >> >>>> are strictly end-to-end, that is, Relays _never_ send > > >> success reports. > > >> >>>> > > >> >>>> The failure report request flag can have three values: > > >> True, False, > > >> >>>> and "partial". If this flag is false, then both the=20 > receiving > > >> >>>> endpoint and any relays MUST NOT send failure=20 > reports. If it is > > >> >>>> "partial", then the receiving device and any relay > > >> SHOULD send an > > >> >>>> error report if it detects a "fatal" error; that is, an > > >> error which > > >> >>>> prevents delivery of the message. > > >> >>>> > > >> >>>> Now, here is the tricky part: None of the conditions > > >> described so > > >> >>>> far involve the use of transaction responses to SEND > > >> requests. If > > >> >>>> the failure report request flag is any value other than > > >> True, then > > >> >>>> MSRP devices SHOULD NOT send transaction responses for > > >> the request. > > >> >>>> Furthermore, devices MUST NOT "expect" transaction=20 > responses, > > >> >>>> although they should not freak out if they get one. > > >> >>>> > > >> >>>> If the failure report request flag is True, then the > > >> recipient, and > > >> >>>> any relays, MUST send send a transaction response.=20 > If any device > > >> >>>> detects an error which prevents delivery, it SHOULD send > > >> a failure > > >> >>>> transaction response back to the previous hop. If it is > > >> unable to > > >> >>>> immediately detect the error, it MAY send a 200 OK response, > > >> >>>> followed by a failure _report_ when the error is > > >> detected. (This is > > >> >>>> mainly for gateway devices, which may not notice=20 > the error until > > >> >>>> they are informed by the downstream network.) > > >> >>>> > > >> >>>> If any relay receives a failure transaction=20 > response to a SEND > > >> >>>> request where failure reports are requested, that device > > >> MUST send a > > >> >>>> failure report. If the sending device receives a failure > > >> transaction > > >> >>>> response, it acts the same as if it had received a > > >> failure report > > >> >>>> with the same information. Furthermore, if any such device > > >> >>>> determines that delivery to the next hop has failed > > >> because either a > > >> >>>> transport error or a locally defined timeout period=20 > has expired > > >> >>>> before receiving a 200 OK response, it MUST act as if it had > > >> >>>> received an appropriate error response. > > >> >>>> > > >> >>>> _______________________________________________ > > >> >>>> 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 > > > > > >This message has been scanned for viruses by MailControl -=20 > >www.mailcontrol.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 13:49:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26848 for ; Thu, 17 Jun 2004 13:49:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb10Y-0003YI-14 for simple-archive@ietf.org; Thu, 17 Jun 2004 13:49:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb0tr-00021W-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 13:42:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb0nX-0000L6-00; Thu, 17 Jun 2004 13:35:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb00e-0000g8-Dv; Thu, 17 Jun 2004 12:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baz9k-0007wE-Fq for simple@megatron.ietf.org; Thu, 17 Jun 2004 11:50: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 LAA12075 for ; Thu, 17 Jun 2004 11:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Baz9j-0006R0-HF for simple@ietf.org; Thu, 17 Jun 2004 11:50:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Baz7q-0005co-00 for simple@ietf.org; Thu, 17 Jun 2004 11:48:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Baz67-0004kp-00 for simple@ietf.org; Thu, 17 Jun 2004 11:46:39 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2004 11:51:41 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5HFk6hD006227; Thu, 17 Jun 2004 11:46:07 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA11476; Thu, 17 Jun 2004 08:46:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 11:46:48 -0400 To: , , From: Mike Hammer Subject: RE: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C8B@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 That would seem to suggest that only a yes/no for the report failure request is needed, not the partial setting, and this is merely behavior (suppress responses) specified on seeing a "yes" setting. Second, you say responses are sent to SEND requests only if "report-failure=no". Does that apply to just endpoints, just relays, or to all devices? Mike At 06:14 PM 6/17/2004 +0300, hisham.khartabil@nokia.com wrote: >I don't understand what is so complicated about this (perhaps Ben >complicated the text too much. You might feel better when you see the text >that will be in the draft). The guts of the proposal is: No responses are >sent to SEND requests unless a negative DSN is requested by the sender. > >Regards, >Hisham > > > -----Original Message----- > > From: ext Mike Hammer [mailto:mhammer@cisco.com] > > Sent: 17.June.2004 17:32 > > To: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > > pkyzivat@cisco.com > > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] MSRP: delivery reports and transaction responses > > > > > > Chris, > > > > If the extra indication is not needed, then there would be no > > need for > > three states in the flag that affects both reports and > > responses. As Paul > > suggested, it depends on how you name the third flag and > > define its usage. > > > > I think if you would define the success and failure flags > > strictly in terms > > of how and when reports are sent or suppressed, then ask what > > is missing, > > you would likely find that the final ingredient is to > > suppress or encourage > > transaction responses by a particular device type at some > > points in the > > flow. You could then define that 3rd flag to do that more specific > > function. That should be a rather simple exercise to try, so > > why not do it? > > > > Mike > > > > > > At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote: > > >I'm with Hisham on this - I think a third flag would just confuse the > > >process. It has been identified that transaction responses are only > > >really needed in one DSN request state (negative=true) - why have a > > >third flag to convey this? > > > > > >Chris. > > > > > > > > > > > > > >I don't like the idea of having a 3rd flag. The flags are > > clearly for > > >the > > > >sender to indicate the desire to receive DSNs or not. The > > transactional > > > >responses are a consequence of that choice. We should not > > mix that with > > > >transactional response flags. Also I don't believe it is a > > good idea to > > > >give the sender the ability to control when responses are sent, > > >especially > > > >when they are useless and don't give any extra information to the > > >sender > > > >nor to the relays, but instead cause useless traffic to flow in the > > > >network. > > > > > > > >Regards, > > > >Hisham > > > > > > > >> -----Original Message----- > > > >> From: simple-bounces@ietf.org > > > >> [mailto:simple-bounces@ietf.org]On Behalf > > > >> Of ext Paul Kyzivat > > > >> Sent: 17.June.2004 03:07 > > > >> To: Mike Hammer > > > >> Cc: Ben Campbell; Simple WG > > > >> Subject: Re: [Simple] MSRP: delivery reports and transaction > > >responses > > > >> > > > >> > > > >> When I read the proposal I had a similar reaction to > > what Mike had. I > > > >> was going to comment but decided it was good enough so I > > > >> would leave it > > > >> be. But since Mike was troubled by the same thing I will > > support him: > > > >> > > > >> It would be clearer if there were three flags rather than > > > >> two, with the > > > >> the third explicitly controlling the sending of > > responses. This does > > > >> permit some nonsense combinations, but they can be > > simply declared > > > >> illegal. (And if anyone uses a nonsense combination they will > > > >> get what > > > >> they deserve.) And with three flags, they would all be binary. > > > >> > > > >> Paul > > > >> > > > >> Mike Hammer wrote: > > > >> > The use of the terms sender and recipient could be > > > >> endpoints or relays, > > > >> > depending on whether you are talking hop-by-hop or > > > >> end-to-end. So, I am > > > >> > a bit fuzzy until some more precise language is provided. > > > >> Otherwise, I > > > >> > am guessing as to exactly what you intended. Your > > fist paragraph > > > >> > indicates that reports are endpoint only, and thus omits > > > >> any discussion > > > >> > of relays. But, then the report failure flag includes > > > >> relay behavior > > > >> > reactions. Thus, my uncertainty and guessing. > > > >> > > > > >> > However, either way, the overall behavior could be the same > > > >> using three > > > >> > flags instead of two. The suggestions were to help confirm > > > >> for myself > > > >> > that I had read your intent correctly. > > > >> > > > > >> > Mike > > > >> > > > > >> > > > > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: > > > >> > > > > >> >> First, just to make sure things are clear, this was not > > > >> proposed draft > > > >> >> verbiage, it was just a quick descripiton of the approach. > > > >> Not only > > > >> >> will the draft language be more precise, we will be > > splitting the > > > >> >> endpoint vs. relay behavior between the appropriate drafts. > > > >> >> > > > >> >> Further comments inline: > > > >> >> > > > >> >> Mike Hammer wrote: > > > >> >> > > > >> >>> Ben, > > > >> >>> It seems like you could simplify things further if you > > > >> de-coupled the > > > >> >>> reports from the responses described in your last 4 > > paragraphs. > > > >> >> > > > >> >> > > > >> >> Do you mean decouple the behavior, or decouple the > > > >> descriptions? If > > > >> >> the first, please let me know what you have in mind. > > > >> >> > > > >> >> This > > > >> >> > > > >> >>> would also help support the clarity you seek in the first > > > >> paragraph > > > >> >>> and enable some symmetry in having only binary > > flags. (Having a > > > >> >>> 'tricky' part is the first clue to complexity.) > > > >> >>> It would also help if you define the behavior upon > > > >> receiving the SEND > > > >> >>> with each flag for each device type (senders, > > endpoints, relays, > > > >> >>> gateways, recipients -- a non-redundant set would help > > > >> readability). > > > >> >>> Lumping two flags or device types in one sentence makes > > > >> parsing more > > > >> >>> difficult. > > > >> >> > > > >> >> > > > >> >> The drafts will do that. > > > >> >> > > > >> >>> Mike > > > >> >>> > > > >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: > > > >> >>> > > > >> >>>> In Boston, we had a proposal for a comprimise solution > > > >> on handling > > > >> >>>> delivery reports and transaction responses. The primary > > > >> contributors > > > >> >>>> have had a number of discussions, and came up with > > some details. > > > >> >>>> This does not address questions of DSN format, nor > > does it talk > > > >> >>>> about DSN reports that occur after a session has > > > >> ended--those will > > > >> >>>> be shortly forthcoming. This note only addresses when to > > > >> send DSN > > > >> >>>> reports and transaction responses, and the relationship > > > >> between them. > > > >> >>>> > > > >> >>>> ----------------------- > > > >> >>>> > > > >> >>>> First, a clarification of terms. When we use the > > term "delivery > > > >> >>>> report" (or "reports" for short), we mean a report sent > > > >> back to the > > > >> >>>> sender to tell it the delivery status. This is > > different than > > > >> >>>> "transaction responses" (or "responses" for short). > > Transaction > > > >> >>>> responses to SEND requests are strictly hop-by-hop, > > > >> while delivery > > > >> >>>> reports are generally end-to-end, or middle-to-end if > > > >> the reporting > > > >> >>>> device is a relay. > > > >> >>>> > > > >> >>>> The sender requests delivery reports on a message by > > > >> message basis. > > > >> >>>> This is done in an MSRP header in a SEND request. That > > > >> header has > > > >> >>>> two distinct flags. One indicates the desire to get > > > >> failure reports, > > > >> >>>> and the other indicates the desire to get success > > reports. The > > > >> >>>> sender can set any combination of these flags. > > > >> >>>> > > > >> >>>> The success report request flag can have values of true > > > >> or false. If > > > >> >>>> the flag is true, then the receiving endpoint MUST > > send back a > > > >> >>>> success report when it successfully receives a message. > > > >> This does > > > >> >>>> not say anything about the message disposition after > > > >> reception, only > > > >> >>>> that is was successfully received. If this flag is > > false, the > > > >> >>>> receiving endpoint MUST NOT send success reports. > > > >> Success reports > > > >> >>>> are strictly end-to-end, that is, Relays _never_ send > > > >> success reports. > > > >> >>>> > > > >> >>>> The failure report request flag can have three values: > > > >> True, False, > > > >> >>>> and "partial". If this flag is false, then both the > > receiving > > > >> >>>> endpoint and any relays MUST NOT send failure > > reports. If it is > > > >> >>>> "partial", then the receiving device and any relay > > > >> SHOULD send an > > > >> >>>> error report if it detects a "fatal" error; that is, an > > > >> error which > > > >> >>>> prevents delivery of the message. > > > >> >>>> > > > >> >>>> Now, here is the tricky part: None of the conditions > > > >> described so > > > >> >>>> far involve the use of transaction responses to SEND > > > >> requests. If > > > >> >>>> the failure report request flag is any value other than > > > >> True, then > > > >> >>>> MSRP devices SHOULD NOT send transaction responses for > > > >> the request. > > > >> >>>> Furthermore, devices MUST NOT "expect" transaction > > responses, > > > >> >>>> although they should not freak out if they get one. > > > >> >>>> > > > >> >>>> If the failure report request flag is True, then the > > > >> recipient, and > > > >> >>>> any relays, MUST send send a transaction response. > > If any device > > > >> >>>> detects an error which prevents delivery, it SHOULD send > > > >> a failure > > > >> >>>> transaction response back to the previous hop. If it is > > > >> unable to > > > >> >>>> immediately detect the error, it MAY send a 200 OK response, > > > >> >>>> followed by a failure _report_ when the error is > > > >> detected. (This is > > > >> >>>> mainly for gateway devices, which may not notice > > the error until > > > >> >>>> they are informed by the downstream network.) > > > >> >>>> > > > >> >>>> If any relay receives a failure transaction > > response to a SEND > > > >> >>>> request where failure reports are requested, that device > > > >> MUST send a > > > >> >>>> failure report. If the sending device receives a failure > > > >> transaction > > > >> >>>> response, it acts the same as if it had received a > > > >> failure report > > > >> >>>> with the same information. Furthermore, if any such device > > > >> >>>> determines that delivery to the next hop has failed > > > >> because either a > > > >> >>>> transport error or a locally defined timeout period > > has expired > > > >> >>>> before receiving a 200 OK response, it MUST act as if it had > > > >> >>>> received an appropriate error response. > > > >> >>>> > > > >> >>>> _______________________________________________ > > > >> >>>> 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 > > > > > > > > >This message has been scanned for viruses by MailControl - > > >www.mailcontrol.com > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 13:53:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27822 for ; Thu, 17 Jun 2004 13:53:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb14w-0004bW-5e for simple-archive@ietf.org; Thu, 17 Jun 2004 13:53:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb10Q-0003Xe-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 13:48:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb0tq-0001wj-00; Thu, 17 Jun 2004 13:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb0FZ-0008RA-Le; Thu, 17 Jun 2004 13:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BazO6-00079h-Ou for simple@megatron.ietf.org; Thu, 17 Jun 2004 12:05: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 MAA13612 for ; Thu, 17 Jun 2004 12:05:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BazO5-0002PZ-Pc for simple@ietf.org; Thu, 17 Jun 2004 12:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BazI4-0000uX-00 for simple@ietf.org; Thu, 17 Jun 2004 11:59:02 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BazCh-0007KX-00 for simple@ietf.org; Thu, 17 Jun 2004 11:53:27 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5HFotLp007638; Thu, 17 Jun 2004 10:50:55 -0500 Message-ID: <40D1BDD5.4030306@dynamicsoft.com> Date: Thu, 17 Jun 2004 10:50:45 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike Hammer wrote: > That would seem to suggest that only a yes/no for the report failure > request is needed, not the partial setting, and this is merely behavior > (suppress responses) specified on seeing a "yes" setting. The "partial" setting was added because some wanted a mode where transaction responses did not occur, but devices were still allowed to send failure reports if they discovered the failure through some other mechanism. > > Second, you say responses are sent to SEND requests only if > "report-failure=no". Does that apply to just endpoints, just relays, or > to all devices? > Uhm, that should be that responses are only sent to SEND requests if report-failures=true. It applies to all devices. > Mike > > At 06:14 PM 6/17/2004 +0300, hisham.khartabil@nokia.com wrote: > >> I don't understand what is so complicated about this (perhaps Ben >> complicated the text too much. You might feel better when you see the >> text that will be in the draft). The guts of the proposal is: No >> responses are sent to SEND requests unless a negative DSN is requested >> by the sender. >> >> Regards, >> Hisham >> >> > -----Original Message----- >> > From: ext Mike Hammer [mailto:mhammer@cisco.com] >> > Sent: 17.June.2004 17:32 >> > To: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >> > pkyzivat@cisco.com >> > Cc: bcampbell@dynamicsoft.com; simple@ietf.org >> > Subject: RE: [Simple] MSRP: delivery reports and transaction responses >> > >> > >> > Chris, >> > >> > If the extra indication is not needed, then there would be no >> > need for >> > three states in the flag that affects both reports and >> > responses. As Paul >> > suggested, it depends on how you name the third flag and >> > define its usage. >> > >> > I think if you would define the success and failure flags >> > strictly in terms >> > of how and when reports are sent or suppressed, then ask what >> > is missing, >> > you would likely find that the final ingredient is to >> > suppress or encourage >> > transaction responses by a particular device type at some >> > points in the >> > flow. You could then define that 3rd flag to do that more specific >> > function. That should be a rather simple exercise to try, so >> > why not do it? >> > >> > Mike >> > >> > >> > At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote: >> > >I'm with Hisham on this - I think a third flag would just confuse the >> > >process. It has been identified that transaction responses are only >> > >really needed in one DSN request state (negative=true) - why have a >> > >third flag to convey this? >> > > >> > >Chris. >> > > >> > > >> > > > >> > > >I don't like the idea of having a 3rd flag. The flags are >> > clearly for >> > >the >> > > >sender to indicate the desire to receive DSNs or not. The >> > transactional >> > > >responses are a consequence of that choice. We should not >> > mix that with >> > > >transactional response flags. Also I don't believe it is a >> > good idea to >> > > >give the sender the ability to control when responses are sent, >> > >especially >> > > >when they are useless and don't give any extra information to the >> > >sender >> > > >nor to the relays, but instead cause useless traffic to flow in the >> > > >network. >> > > > >> > > >Regards, >> > > >Hisham >> > > > >> > > >> -----Original Message----- >> > > >> From: simple-bounces@ietf.org >> > > >> [mailto:simple-bounces@ietf.org]On Behalf >> > > >> Of ext Paul Kyzivat >> > > >> Sent: 17.June.2004 03:07 >> > > >> To: Mike Hammer >> > > >> Cc: Ben Campbell; Simple WG >> > > >> Subject: Re: [Simple] MSRP: delivery reports and transaction >> > >responses >> > > >> >> > > >> >> > > >> When I read the proposal I had a similar reaction to >> > what Mike had. I >> > > >> was going to comment but decided it was good enough so I >> > > >> would leave it >> > > >> be. But since Mike was troubled by the same thing I will >> > support him: >> > > >> >> > > >> It would be clearer if there were three flags rather than >> > > >> two, with the >> > > >> the third explicitly controlling the sending of >> > responses. This does >> > > >> permit some nonsense combinations, but they can be >> > simply declared >> > > >> illegal. (And if anyone uses a nonsense combination they will >> > > >> get what >> > > >> they deserve.) And with three flags, they would all be binary. >> > > >> >> > > >> Paul >> > > >> >> > > >> Mike Hammer wrote: >> > > >> > The use of the terms sender and recipient could be >> > > >> endpoints or relays, >> > > >> > depending on whether you are talking hop-by-hop or >> > > >> end-to-end. So, I am >> > > >> > a bit fuzzy until some more precise language is provided. >> > > >> Otherwise, I >> > > >> > am guessing as to exactly what you intended. Your >> > fist paragraph >> > > >> > indicates that reports are endpoint only, and thus omits >> > > >> any discussion >> > > >> > of relays. But, then the report failure flag includes >> > > >> relay behavior >> > > >> > reactions. Thus, my uncertainty and guessing. >> > > >> > >> > > >> > However, either way, the overall behavior could be the same >> > > >> using three >> > > >> > flags instead of two. The suggestions were to help confirm >> > > >> for myself >> > > >> > that I had read your intent correctly. >> > > >> > >> > > >> > Mike >> > > >> > >> > > >> > >> > > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: >> > > >> > >> > > >> >> First, just to make sure things are clear, this was not >> > > >> proposed draft >> > > >> >> verbiage, it was just a quick descripiton of the approach. >> > > >> Not only >> > > >> >> will the draft language be more precise, we will be >> > splitting the >> > > >> >> endpoint vs. relay behavior between the appropriate drafts. >> > > >> >> >> > > >> >> Further comments inline: >> > > >> >> >> > > >> >> Mike Hammer wrote: >> > > >> >> >> > > >> >>> Ben, >> > > >> >>> It seems like you could simplify things further if you >> > > >> de-coupled the >> > > >> >>> reports from the responses described in your last 4 >> > paragraphs. >> > > >> >> >> > > >> >> >> > > >> >> Do you mean decouple the behavior, or decouple the >> > > >> descriptions? If >> > > >> >> the first, please let me know what you have in mind. >> > > >> >> >> > > >> >> This >> > > >> >> >> > > >> >>> would also help support the clarity you seek in the first >> > > >> paragraph >> > > >> >>> and enable some symmetry in having only binary >> > flags. (Having a >> > > >> >>> 'tricky' part is the first clue to complexity.) >> > > >> >>> It would also help if you define the behavior upon >> > > >> receiving the SEND >> > > >> >>> with each flag for each device type (senders, >> > endpoints, relays, >> > > >> >>> gateways, recipients -- a non-redundant set would help >> > > >> readability). >> > > >> >>> Lumping two flags or device types in one sentence makes >> > > >> parsing more >> > > >> >>> difficult. >> > > >> >> >> > > >> >> >> > > >> >> The drafts will do that. >> > > >> >> >> > > >> >>> Mike >> > > >> >>> >> > > >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >> > > >> >>> >> > > >> >>>> In Boston, we had a proposal for a comprimise solution >> > > >> on handling >> > > >> >>>> delivery reports and transaction responses. The primary >> > > >> contributors >> > > >> >>>> have had a number of discussions, and came up with >> > some details. >> > > >> >>>> This does not address questions of DSN format, nor >> > does it talk >> > > >> >>>> about DSN reports that occur after a session has >> > > >> ended--those will >> > > >> >>>> be shortly forthcoming. This note only addresses when to >> > > >> send DSN >> > > >> >>>> reports and transaction responses, and the relationship >> > > >> between them. >> > > >> >>>> >> > > >> >>>> ----------------------- >> > > >> >>>> >> > > >> >>>> First, a clarification of terms. When we use the >> > term "delivery >> > > >> >>>> report" (or "reports" for short), we mean a report sent >> > > >> back to the >> > > >> >>>> sender to tell it the delivery status. This is >> > different than >> > > >> >>>> "transaction responses" (or "responses" for short). >> > Transaction >> > > >> >>>> responses to SEND requests are strictly hop-by-hop, >> > > >> while delivery >> > > >> >>>> reports are generally end-to-end, or middle-to-end if >> > > >> the reporting >> > > >> >>>> device is a relay. >> > > >> >>>> >> > > >> >>>> The sender requests delivery reports on a message by >> > > >> message basis. >> > > >> >>>> This is done in an MSRP header in a SEND request. That >> > > >> header has >> > > >> >>>> two distinct flags. One indicates the desire to get >> > > >> failure reports, >> > > >> >>>> and the other indicates the desire to get success >> > reports. The >> > > >> >>>> sender can set any combination of these flags. >> > > >> >>>> >> > > >> >>>> The success report request flag can have values of true >> > > >> or false. If >> > > >> >>>> the flag is true, then the receiving endpoint MUST >> > send back a >> > > >> >>>> success report when it successfully receives a message. >> > > >> This does >> > > >> >>>> not say anything about the message disposition after >> > > >> reception, only >> > > >> >>>> that is was successfully received. If this flag is >> > false, the >> > > >> >>>> receiving endpoint MUST NOT send success reports. >> > > >> Success reports >> > > >> >>>> are strictly end-to-end, that is, Relays _never_ send >> > > >> success reports. >> > > >> >>>> >> > > >> >>>> The failure report request flag can have three values: >> > > >> True, False, >> > > >> >>>> and "partial". If this flag is false, then both the >> > receiving >> > > >> >>>> endpoint and any relays MUST NOT send failure >> > reports. If it is >> > > >> >>>> "partial", then the receiving device and any relay >> > > >> SHOULD send an >> > > >> >>>> error report if it detects a "fatal" error; that is, an >> > > >> error which >> > > >> >>>> prevents delivery of the message. >> > > >> >>>> >> > > >> >>>> Now, here is the tricky part: None of the conditions >> > > >> described so >> > > >> >>>> far involve the use of transaction responses to SEND >> > > >> requests. If >> > > >> >>>> the failure report request flag is any value other than >> > > >> True, then >> > > >> >>>> MSRP devices SHOULD NOT send transaction responses for >> > > >> the request. >> > > >> >>>> Furthermore, devices MUST NOT "expect" transaction >> > responses, >> > > >> >>>> although they should not freak out if they get one. >> > > >> >>>> >> > > >> >>>> If the failure report request flag is True, then the >> > > >> recipient, and >> > > >> >>>> any relays, MUST send send a transaction response. >> > If any device >> > > >> >>>> detects an error which prevents delivery, it SHOULD send >> > > >> a failure >> > > >> >>>> transaction response back to the previous hop. If it is >> > > >> unable to >> > > >> >>>> immediately detect the error, it MAY send a 200 OK response, >> > > >> >>>> followed by a failure _report_ when the error is >> > > >> detected. (This is >> > > >> >>>> mainly for gateway devices, which may not notice >> > the error until >> > > >> >>>> they are informed by the downstream network.) >> > > >> >>>> >> > > >> >>>> If any relay receives a failure transaction >> > response to a SEND >> > > >> >>>> request where failure reports are requested, that device >> > > >> MUST send a >> > > >> >>>> failure report. If the sending device receives a failure >> > > >> transaction >> > > >> >>>> response, it acts the same as if it had received a >> > > >> failure report >> > > >> >>>> with the same information. Furthermore, if any such device >> > > >> >>>> determines that delivery to the next hop has failed >> > > >> because either a >> > > >> >>>> transport error or a locally defined timeout period >> > has expired >> > > >> >>>> before receiving a 200 OK response, it MUST act as if it had >> > > >> >>>> received an appropriate error response. >> > > >> >>>> >> > > >> >>>> _______________________________________________ >> > > >> >>>> 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 >> > > >> > > >> > >This message has been scanned for viruses by MailControl - >> > >www.mailcontrol.com >> > >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 14:22:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01357 for ; Thu, 17 Jun 2004 14:22:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb1Wo-000511-Kt for simple-archive@ietf.org; Thu, 17 Jun 2004 14:22:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb1SS-0003xU-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 14:17:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb1Ql-0003RW-02; Thu, 17 Jun 2004 14:16:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bb1Ju-0006n6-Su; Thu, 17 Jun 2004 14:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb0tD-000061-De; Thu, 17 Jun 2004 13:41:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb0Ea-0007tv-G8 for simple@megatron.ietf.org; Thu, 17 Jun 2004 12:59: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 MAA20742 for ; Thu, 17 Jun 2004 12:59:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb0EZ-0007ff-Ag for simple@ietf.org; Thu, 17 Jun 2004 12:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb09N-0006IO-00 for simple@ietf.org; Thu, 17 Jun 2004 12:54:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb023-0004bj-00 for simple@ietf.org; Thu, 17 Jun 2004 12:46:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bazvt-00008v-FU for simple@ietf.org; Thu, 17 Jun 2004 12:40:09 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2004 12:45:08 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5HGdRhH016286; Thu, 17 Jun 2004 12:39:33 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA15654; Thu, 17 Jun 2004 09:38:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 12:39:05 -0400 To: Ben Campbell From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D1BDD5.4030306@dynamicsoft.com> References: <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Drilling down just a little bit further inline. At 10:50 AM 6/17/2004 -0500, Ben Campbell wrote: >Mike Hammer wrote: > >>That would seem to suggest that only a yes/no for the report failure >>request is needed, not the partial setting, and this is merely behavior >>(suppress responses) specified on seeing a "yes" setting. > >The "partial" setting was added because some wanted a mode where >transaction responses did not occur, but devices were still allowed to >send failure reports if they discovered the failure through some other >mechanism. So the partial applies only to negative-DSN sending, not to response sending. (this is the schizophrenic part) This is where a "Neg-DSN-possible-override" flag would be the third flag. Would it not be possible to use just two binary flags and just make the behavior of the receiving node a "Should not send DSN, MUST not send response" with the sending node having a "MAY discard received DSN" or is this a limited BW case for the sender? I would think that a relay for BW-limited sender could also discard before a BW-limited link. >>Second, you say responses are sent to SEND requests only if >>"report-failure=no". Does that apply to just endpoints, just relays, or >>to all devices? > >Uhm, that should be that responses are only sent to SEND requests if >report-failures=true. It applies to all devices. My bad, tried to put positive spin on requirement, seemed like too many negatives in one sentence. So to summarize: report-success=true send response?, send Pos-DSN report report-success=false send response?, no Pos-DSN report report-failures=true send response, send Neg-DSN report report-failures=false no response, no report report-failures=partial no response, may send report applies to all devices. I'm still missing some details (? above). Mike >>Mike >>At 06:14 PM 6/17/2004 +0300, hisham.khartabil@nokia.com wrote: >> >>>I don't understand what is so complicated about this (perhaps Ben >>>complicated the text too much. You might feel better when you see the >>>text that will be in the draft). The guts of the proposal is: No >>>responses are sent to SEND requests unless a negative DSN is requested >>>by the sender. >>> >>>Regards, >>>Hisham >>> >>> > -----Original Message----- >>> > From: ext Mike Hammer [mailto:mhammer@cisco.com] >>> > Sent: 17.June.2004 17:32 >>> > To: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>> > pkyzivat@cisco.com >>> > Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>> > Subject: RE: [Simple] MSRP: delivery reports and transaction responses >>> > >>> > >>> > Chris, >>> > >>> > If the extra indication is not needed, then there would be no >>> > need for >>> > three states in the flag that affects both reports and >>> > responses. As Paul >>> > suggested, it depends on how you name the third flag and >>> > define its usage. >>> > >>> > I think if you would define the success and failure flags >>> > strictly in terms >>> > of how and when reports are sent or suppressed, then ask what >>> > is missing, >>> > you would likely find that the final ingredient is to >>> > suppress or encourage >>> > transaction responses by a particular device type at some >>> > points in the >>> > flow. You could then define that 3rd flag to do that more specific >>> > function. That should be a rather simple exercise to try, so >>> > why not do it? >>> > >>> > Mike >>> > >>> > >>> > At 10:48 AM 6/17/2004 +0100, Chris Boulton wrote: >>> > >I'm with Hisham on this - I think a third flag would just confuse the >>> > >process. It has been identified that transaction responses are only >>> > >really needed in one DSN request state (negative=true) - why have a >>> > >third flag to convey this? >>> > > >>> > >Chris. >>> > > >>> > > >>> > > > >>> > > >I don't like the idea of having a 3rd flag. The flags are >>> > clearly for >>> > >the >>> > > >sender to indicate the desire to receive DSNs or not. The >>> > transactional >>> > > >responses are a consequence of that choice. We should not >>> > mix that with >>> > > >transactional response flags. Also I don't believe it is a >>> > good idea to >>> > > >give the sender the ability to control when responses are sent, >>> > >especially >>> > > >when they are useless and don't give any extra information to the >>> > >sender >>> > > >nor to the relays, but instead cause useless traffic to flow in the >>> > > >network. >>> > > > >>> > > >Regards, >>> > > >Hisham >>> > > > >>> > > >> -----Original Message----- >>> > > >> From: simple-bounces@ietf.org >>> > > >> [mailto:simple-bounces@ietf.org]On Behalf >>> > > >> Of ext Paul Kyzivat >>> > > >> Sent: 17.June.2004 03:07 >>> > > >> To: Mike Hammer >>> > > >> Cc: Ben Campbell; Simple WG >>> > > >> Subject: Re: [Simple] MSRP: delivery reports and transaction >>> > >responses >>> > > >> >>> > > >> >>> > > >> When I read the proposal I had a similar reaction to >>> > what Mike had. I >>> > > >> was going to comment but decided it was good enough so I >>> > > >> would leave it >>> > > >> be. But since Mike was troubled by the same thing I will >>> > support him: >>> > > >> >>> > > >> It would be clearer if there were three flags rather than >>> > > >> two, with the >>> > > >> the third explicitly controlling the sending of >>> > responses. This does >>> > > >> permit some nonsense combinations, but they can be >>> > simply declared >>> > > >> illegal. (And if anyone uses a nonsense combination they will >>> > > >> get what >>> > > >> they deserve.) And with three flags, they would all be binary. >>> > > >> >>> > > >> Paul >>> > > >> >>> > > >> Mike Hammer wrote: >>> > > >> > The use of the terms sender and recipient could be >>> > > >> endpoints or relays, >>> > > >> > depending on whether you are talking hop-by-hop or >>> > > >> end-to-end. So, I am >>> > > >> > a bit fuzzy until some more precise language is provided. >>> > > >> Otherwise, I >>> > > >> > am guessing as to exactly what you intended. Your >>> > fist paragraph >>> > > >> > indicates that reports are endpoint only, and thus omits >>> > > >> any discussion >>> > > >> > of relays. But, then the report failure flag includes >>> > > >> relay behavior >>> > > >> > reactions. Thus, my uncertainty and guessing. >>> > > >> > >>> > > >> > However, either way, the overall behavior could be the same >>> > > >> using three >>> > > >> > flags instead of two. The suggestions were to help confirm >>> > > >> for myself >>> > > >> > that I had read your intent correctly. >>> > > >> > >>> > > >> > Mike >>> > > >> > >>> > > >> > >>> > > >> > At 05:51 PM 6/16/2004 -0500, Ben Campbell wrote: >>> > > >> > >>> > > >> >> First, just to make sure things are clear, this was not >>> > > >> proposed draft >>> > > >> >> verbiage, it was just a quick descripiton of the approach. >>> > > >> Not only >>> > > >> >> will the draft language be more precise, we will be >>> > splitting the >>> > > >> >> endpoint vs. relay behavior between the appropriate drafts. >>> > > >> >> >>> > > >> >> Further comments inline: >>> > > >> >> >>> > > >> >> Mike Hammer wrote: >>> > > >> >> >>> > > >> >>> Ben, >>> > > >> >>> It seems like you could simplify things further if you >>> > > >> de-coupled the >>> > > >> >>> reports from the responses described in your last 4 >>> > paragraphs. >>> > > >> >> >>> > > >> >> >>> > > >> >> Do you mean decouple the behavior, or decouple the >>> > > >> descriptions? If >>> > > >> >> the first, please let me know what you have in mind. >>> > > >> >> >>> > > >> >> This >>> > > >> >> >>> > > >> >>> would also help support the clarity you seek in the first >>> > > >> paragraph >>> > > >> >>> and enable some symmetry in having only binary >>> > flags. (Having a >>> > > >> >>> 'tricky' part is the first clue to complexity.) >>> > > >> >>> It would also help if you define the behavior upon >>> > > >> receiving the SEND >>> > > >> >>> with each flag for each device type (senders, >>> > endpoints, relays, >>> > > >> >>> gateways, recipients -- a non-redundant set would help >>> > > >> readability). >>> > > >> >>> Lumping two flags or device types in one sentence makes >>> > > >> parsing more >>> > > >> >>> difficult. >>> > > >> >> >>> > > >> >> >>> > > >> >> The drafts will do that. >>> > > >> >> >>> > > >> >>> Mike >>> > > >> >>> >>> > > >> >>> At 02:16 PM 6/16/2004 -0500, Ben Campbell wrote: >>> > > >> >>> >>> > > >> >>>> In Boston, we had a proposal for a comprimise solution >>> > > >> on handling >>> > > >> >>>> delivery reports and transaction responses. The primary >>> > > >> contributors >>> > > >> >>>> have had a number of discussions, and came up with >>> > some details. >>> > > >> >>>> This does not address questions of DSN format, nor >>> > does it talk >>> > > >> >>>> about DSN reports that occur after a session has >>> > > >> ended--those will >>> > > >> >>>> be shortly forthcoming. This note only addresses when to >>> > > >> send DSN >>> > > >> >>>> reports and transaction responses, and the relationship >>> > > >> between them. >>> > > >> >>>> >>> > > >> >>>> ----------------------- >>> > > >> >>>> >>> > > >> >>>> First, a clarification of terms. When we use the >>> > term "delivery >>> > > >> >>>> report" (or "reports" for short), we mean a report sent >>> > > >> back to the >>> > > >> >>>> sender to tell it the delivery status. This is >>> > different than >>> > > >> >>>> "transaction responses" (or "responses" for short). >>> > Transaction >>> > > >> >>>> responses to SEND requests are strictly hop-by-hop, >>> > > >> while delivery >>> > > >> >>>> reports are generally end-to-end, or middle-to-end if >>> > > >> the reporting >>> > > >> >>>> device is a relay. >>> > > >> >>>> >>> > > >> >>>> The sender requests delivery reports on a message by >>> > > >> message basis. >>> > > >> >>>> This is done in an MSRP header in a SEND request. That >>> > > >> header has >>> > > >> >>>> two distinct flags. One indicates the desire to get >>> > > >> failure reports, >>> > > >> >>>> and the other indicates the desire to get success >>> > reports. The >>> > > >> >>>> sender can set any combination of these flags. >>> > > >> >>>> >>> > > >> >>>> The success report request flag can have values of true >>> > > >> or false. If >>> > > >> >>>> the flag is true, then the receiving endpoint MUST >>> > send back a >>> > > >> >>>> success report when it successfully receives a message. >>> > > >> This does >>> > > >> >>>> not say anything about the message disposition after >>> > > >> reception, only >>> > > >> >>>> that is was successfully received. If this flag is >>> > false, the >>> > > >> >>>> receiving endpoint MUST NOT send success reports. >>> > > >> Success reports >>> > > >> >>>> are strictly end-to-end, that is, Relays _never_ send >>> > > >> success reports. >>> > > >> >>>> >>> > > >> >>>> The failure report request flag can have three values: >>> > > >> True, False, >>> > > >> >>>> and "partial". If this flag is false, then both the >>> > receiving >>> > > >> >>>> endpoint and any relays MUST NOT send failure >>> > reports. If it is >>> > > >> >>>> "partial", then the receiving device and any relay >>> > > >> SHOULD send an >>> > > >> >>>> error report if it detects a "fatal" error; that is, an >>> > > >> error which >>> > > >> >>>> prevents delivery of the message. >>> > > >> >>>> >>> > > >> >>>> Now, here is the tricky part: None of the conditions >>> > > >> described so >>> > > >> >>>> far involve the use of transaction responses to SEND >>> > > >> requests. If >>> > > >> >>>> the failure report request flag is any value other than >>> > > >> True, then >>> > > >> >>>> MSRP devices SHOULD NOT send transaction responses for >>> > > >> the request. >>> > > >> >>>> Furthermore, devices MUST NOT "expect" transaction >>> > responses, >>> > > >> >>>> although they should not freak out if they get one. >>> > > >> >>>> >>> > > >> >>>> If the failure report request flag is True, then the >>> > > >> recipient, and >>> > > >> >>>> any relays, MUST send send a transaction response. >>> > If any device >>> > > >> >>>> detects an error which prevents delivery, it SHOULD send >>> > > >> a failure >>> > > >> >>>> transaction response back to the previous hop. If it is >>> > > >> unable to >>> > > >> >>>> immediately detect the error, it MAY send a 200 OK response, >>> > > >> >>>> followed by a failure _report_ when the error is >>> > > >> detected. (This is >>> > > >> >>>> mainly for gateway devices, which may not notice >>> > the error until >>> > > >> >>>> they are informed by the downstream network.) >>> > > >> >>>> >>> > > >> >>>> If any relay receives a failure transaction >>> > response to a SEND >>> > > >> >>>> request where failure reports are requested, that device >>> > > >> MUST send a >>> > > >> >>>> failure report. If the sending device receives a failure >>> > > >> transaction >>> > > >> >>>> response, it acts the same as if it had received a >>> > > >> failure report >>> > > >> >>>> with the same information. Furthermore, if any such device >>> > > >> >>>> determines that delivery to the next hop has failed >>> > > >> because either a >>> > > >> >>>> transport error or a locally defined timeout period >>> > has expired >>> > > >> >>>> before receiving a 200 OK response, it MUST act as if it had >>> > > >> >>>> received an appropriate error response. >>> > > >> >>>> >>> > > >> >>>> _______________________________________________ >>> > > >> >>>> 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 >>> > > >>> > > >>> > >This message has been scanned for viruses by MailControl - >>> > >www.mailcontrol.com >>> > >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 14:28:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02435 for ; Thu, 17 Jun 2004 14:28:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb1cu-0006xN-07 for simple-archive@ietf.org; Thu, 17 Jun 2004 14:28:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb1aq-0006CO-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 14:26:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb1XY-0005An-00; Thu, 17 Jun 2004 14:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb1GL-0001Mr-RF; Thu, 17 Jun 2004 14:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb0s8-0007Ts-Io for simple@megatron.ietf.org; Thu, 17 Jun 2004 13:40: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 NAA25733 for ; Thu, 17 Jun 2004 13:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb0s6-0001hT-QQ for simple@ietf.org; Thu, 17 Jun 2004 13:40:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb0kM-0007fE-00 for simple@ietf.org; Thu, 17 Jun 2004 13:32:19 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bb0ap-0005WU-00 for simple@ietf.org; Thu, 17 Jun 2004 13:22:27 -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 i5HHKvLx011483; Thu, 17 Jun 2004 12:20:57 -0500 (CDT) Received: from [63.110.3.184] (dhcp184.dfw.dynamicsoft.com [63.110.3.184]) by DYN-TX-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KZRBQDK3; Thu, 17 Jun 2004 12:20:57 -0500 Message-ID: <40D1D2ED.7050200@dynamicsoft.com> Date: Thu, 17 Jun 2004 12:20:45 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> <40D0E0A0.8040000@cisco.com> In-Reply-To: <40D0E0A0.8040000@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Mike Hammer , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > It would be clearer if there were three flags rather than two, with > the the third explicitly controlling the sending of responses. This > does permit some nonsense combinations, but they can be simply > declared illegal. (And if anyone uses a nonsense combination they will > get what they deserve.) And with three flags, they would all be binary. I think such an approach is a bad idea. It's good protocol design to make things that are semantically nonsensical syntactically impossible to express. Separating out a "responses" flag will just obscure the fact that twiddling this flag over here with a name unrelated to negative DSNs has a fairly radical effect on the nature of the negative DSNs you might receive. Although the wording of the description could use some tightening, I strongly support leaving the mechanism that is being described as Ben proposed. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 15:24:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07535 for ; Thu, 17 Jun 2004 15:24:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2UY-0001rv-Kj for simple-archive@ietf.org; Thu, 17 Jun 2004 15:24:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2To-0001WB-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 15:23:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2Sa-0000vx-00; Thu, 17 Jun 2004 15:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2Dn-00071F-5P; Thu, 17 Jun 2004 15:06:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb1uQ-0003gv-U3 for simple@megatron.ietf.org; Thu, 17 Jun 2004 14:46:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04086 for ; Thu, 17 Jun 2004 14:46:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb1uP-0005RY-Rn for simple@ietf.org; Thu, 17 Jun 2004 14:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb1tR-00056g-00 for simple@ietf.org; Thu, 17 Jun 2004 14:45:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bb1sW-0004V6-00 for simple@ietf.org; Thu, 17 Jun 2004 14:44:48 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2004 14:44:38 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5HIiEhD013360; Thu, 17 Jun 2004 14:44:15 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJM70489; Thu, 17 Jun 2004 14:44:13 -0400 (EDT) Message-ID: <40D1E67D.6020905@cisco.com> Date: Thu, 17 Jun 2004 14:44:13 -0400 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: Adam Roach Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> <40D0E0A0.8040000@cisco.com> <40D1D2ED.7050200@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Ben Campbell , Mike Hammer , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Paul Kyzivat wrote: > >> It would be clearer if there were three flags rather than two, with >> the the third explicitly controlling the sending of responses. This >> does permit some nonsense combinations, but they can be simply >> declared illegal. (And if anyone uses a nonsense combination they will >> get what they deserve.) And with three flags, they would all be binary. > > > I think such an approach is a bad idea. > > It's good protocol design to make things that are semantically > nonsensical syntactically impossible to express. Well, I agree with you on that. But it is a principle that is violated quite regularly in sip, with many constraints being expressed in the text rather than the syntax. Its a tradeoff vs other goals. And the flip side of that is to carefully define the semantics of everything that it is possible to specify semantically. > Separating out a > "responses" flag will just obscure the fact that twiddling this flag > over here with a name unrelated to negative DSNs has a fairly radical > effect on the nature of the negative DSNs you might receive. True. > Although the wording of the description could use some tightening, I > strongly support leaving the mechanism that is being described as Ben > proposed. If the syntax and/or description can be made less obscure I have no problem. I was baffled by true/partial/false, and the description left me still scratching my head. I *thought* I understood it, but wasn't certain. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 15:32:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08068 for ; Thu, 17 Jun 2004 15:32:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2cs-0004fj-2o for simple-archive@ietf.org; Thu, 17 Jun 2004 15:32:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2c0-0004NY-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 15:31:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2bR-00041r-00; Thu, 17 Jun 2004 15:31:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2TK-0000HY-1F; Thu, 17 Jun 2004 15:22:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2Do-000724-BI for simple@megatron.ietf.org; Thu, 17 Jun 2004 15:06: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 PAA05335 for ; Thu, 17 Jun 2004 15:06:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2Dn-0003pS-7s for simple@ietf.org; Thu, 17 Jun 2004 15:06:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2Cm-0003Vm-00 for simple@ietf.org; Thu, 17 Jun 2004 15:05:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2Bq-0002va-00 for simple@ietf.org; Thu, 17 Jun 2004 15:04:46 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2004 15:04:37 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5HJ4D4w027044; Thu, 17 Jun 2004 15:04:14 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA30542; Thu, 17 Jun 2004 12:04:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617140245.00b50b48@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 15:05:04 -0400 To: Adam Roach , Paul Kyzivat From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D1D2ED.7050200@dynamicsoft.com> References: <40D0E0A0.8040000@cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> <40D0E0A0.8040000@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ben Campbell , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 12:20 PM 6/17/2004 -0500, Adam Roach wrote: >Paul Kyzivat wrote: > >>It would be clearer if there were three flags rather than two, with the >>the third explicitly controlling the sending of responses. This does >>permit some nonsense combinations, but they can be simply declared >>illegal. (And if anyone uses a nonsense combination they will get what >>they deserve.) And with three flags, they would all be binary. > >I think such an approach is a bad idea. > >It's good protocol design to make things that are semantically nonsensical >syntactically impossible to express. True, but the definitions of the 3 flags could be made such that there are no non-sensical meanings. >Separating out a "responses" flag will just obscure the fact that >twiddling this flag over here with a name unrelated to negative DSNs has a >fairly radical effect on the nature of the negative DSNs you might receive. >Although the wording of the description could use some tightening, I >strongly support leaving the mechanism that is being described as Ben proposed. > >/a It is still unclear to me from the sender's viewpoint the difference between Report-failure:yes and partial. Either he will accept DNS or he won't, unless there are really two types of DNS, in which case they should be distinguished. Another alternative, if you are going for minimum numbers of flags would have been to define it as: default send only Pos-Res, except when this is received: Report: 1*( Pos-DNS [","] / Neg-DNS [","] / Neg-Res [","] ) Or, for two flags: Report-DNS: 1*( success [","] / fail ) Suppress-Res: 1*( true / false ) ; absent = false However, this may be water under the bridge. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 15:42:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08490 for ; Thu, 17 Jun 2004 15:42:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2mp-00000W-Ot for simple-archive@ietf.org; Thu, 17 Jun 2004 15:42:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2mJ-0007U8-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 15:42:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2l0-00077Y-00; Thu, 17 Jun 2004 15:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2Zn-0002QT-AW; Thu, 17 Jun 2004 15:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2JT-0001z5-55 for simple@megatron.ietf.org; Thu, 17 Jun 2004 15:12: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 PAA06176 for ; Thu, 17 Jun 2004 15:12:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2JS-0005ZK-0t for simple@ietf.org; Thu, 17 Jun 2004 15:12:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2HU-0005CE-00 for simple@ietf.org; Thu, 17 Jun 2004 15:10:36 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb2GQ-0004XK-00 for simple@ietf.org; Thu, 17 Jun 2004 15:09:30 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5HJ7YLp008535; Thu, 17 Jun 2004 14:07:35 -0500 Message-ID: <40D1EBEC.1040600@dynamicsoft.com> Date: Thu, 17 Jun 2004 14:07:24 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <40D0E0A0.8040000@cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> <40D0E0A0.8040000@cisco.com> <4.3.2.7.2.20040617140245.00b50b48@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040617140245.00b50b48@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Adam Roach , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike Hammer wrote: > At 12:20 PM 6/17/2004 -0500, Adam Roach wrote: > >> Paul Kyzivat wrote: >> >>> It would be clearer if there were three flags rather than two, with >>> the the third explicitly controlling the sending of responses. This >>> does permit some nonsense combinations, but they can be simply >>> declared illegal. (And if anyone uses a nonsense combination they >>> will get what they deserve.) And with three flags, they would all be >>> binary. >> >> >> I think such an approach is a bad idea. >> >> It's good protocol design to make things that are semantically >> nonsensical syntactically impossible to express. > > > True, but the definitions of the 3 flags could be made such that there > are no non-sensical meanings. > >> Separating out a "responses" flag will just obscure the fact that >> twiddling this flag over here with a name unrelated to negative DSNs >> has a fairly radical effect on the nature of the negative DSNs you >> might receive. >> Although the wording of the description could use some tightening, I >> strongly support leaving the mechanism that is being described as Ben >> proposed. >> >> /a > > > It is still unclear to me from the sender's viewpoint the difference > between Report-failure:yes and partial. Either he will accept DNS or he > won't, unless there are really two types of DNS, in which case they > should be distinguished. Report-failure=true means the sender insists on getting failure reports if a failure occures. Partial means that is does not forbid the sending of failure reports. False means it forbids the sending of failure reports. > > Another alternative, if you are going for minimum numbers of flags would > have been to define it as: default send only Pos-Res, except when this > is received: > > Report: 1*( Pos-DNS [","] / Neg-DNS [","] / Neg-Res [","] ) > > Or, for two flags: > > Report-DNS: 1*( success [","] / fail ) > Suppress-Res: 1*( true / false ) ; absent = false > > However, this may be water under the bridge. > > Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 16:08:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10043 for ; Thu, 17 Jun 2004 16:08:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3BQ-0000kP-E8 for simple-archive@ietf.org; Thu, 17 Jun 2004 16:08:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3AY-0000Rp-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 16:07:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb39r-00004d-00; Thu, 17 Jun 2004 16:06:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2wx-000186-WF; Thu, 17 Jun 2004 15:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2mC-0006Xy-JO for simple@megatron.ietf.org; Thu, 17 Jun 2004 15:42: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 PAA08433 for ; Thu, 17 Jun 2004 15:42:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2mB-0007Ss-BM for simple@ietf.org; Thu, 17 Jun 2004 15:42:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2kZ-000796-00 for simple@ietf.org; Thu, 17 Jun 2004 15:40:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2jb-0006YR-00 for simple@ietf.org; Thu, 17 Jun 2004 15:39:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2004 15:39:30 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5HJd74w003483; Thu, 17 Jun 2004 15:39:07 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA33624; Thu, 17 Jun 2004 12:39:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617152817.00b1b7a8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 15:39:57 -0400 To: Ben Campbell From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D1EBEC.1040600@dynamicsoft.com> References: <4.3.2.7.2.20040617140245.00b50b48@cia.cisco.com> <40D0E0A0.8040000@cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616183257.031c38a8@cia.cisco.com> <4.3.2.7.2.20040616190312.00b1a8d0@cia.cisco.com> <40D0E0A0.8040000@cisco.com> <4.3.2.7.2.20040617140245.00b50b48@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Paul Kyzivat , Adam Roach , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Ben, I think I've teased this enough to understand it, but still need to nail down one detail. Could you confirm my understanding below: Failure responses are tied to the report-failure flag, true means they are sent, false means they are not, in all cases by all devices. Success responses are not tied to the report-success flag, they are reported at all times by all devices. Final note, then I'll be quiet: Since response behavior is implicit, i.e. embedded in the *report* flags, and not explicitly signaled, any need to de-couple and change the response behavior in the future will have backward compatibility problems. Thanks for your patience for one who was not in Boston, Mike At 02:07 PM 6/17/2004 -0500, Ben Campbell wrote: >Mike Hammer wrote: > >>At 12:20 PM 6/17/2004 -0500, Adam Roach wrote: >> >>>Paul Kyzivat wrote: >>> >>>>It would be clearer if there were three flags rather than two, with the >>>>the third explicitly controlling the sending of responses. This does >>>>permit some nonsense combinations, but they can be simply declared >>>>illegal. (And if anyone uses a nonsense combination they will get what >>>>they deserve.) And with three flags, they would all be binary. >>> >>> >>>I think such an approach is a bad idea. >>> >>>It's good protocol design to make things that are semantically >>>nonsensical syntactically impossible to express. >> >>True, but the definitions of the 3 flags could be made such that there >>are no non-sensical meanings. >> >>>Separating out a "responses" flag will just obscure the fact that >>>twiddling this flag over here with a name unrelated to negative DSNs has >>>a fairly radical effect on the nature of the negative DSNs you might receive. >>>Although the wording of the description could use some tightening, I >>>strongly support leaving the mechanism that is being described as Ben proposed. >>> >>>/a >> >>It is still unclear to me from the sender's viewpoint the difference >>between Report-failure:yes and partial. Either he will accept DNS or he >>won't, unless there are really two types of DNS, in which case they >>should be distinguished. > >Report-failure=true means the sender insists on getting failure reports if >a failure occures. Partial means that is does not forbid the sending of >failure reports. False means it forbids the sending of failure reports. > > > >>Another alternative, if you are going for minimum numbers of flags would >>have been to define it as: default send only Pos-Res, except when this >>is received: >>Report: 1*( Pos-DNS [","] / Neg-DNS [","] / Neg-Res [","] ) >>Or, for two flags: >>Report-DNS: 1*( success [","] / fail ) >>Suppress-Res: 1*( true / false ) ; absent = false >>However, this may be water under the bridge. >>Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 18:48:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23355 for ; Thu, 17 Jun 2004 18:48:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb5gP-0006BR-Mb for simple-archive@ietf.org; Thu, 17 Jun 2004 18:48:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb5fb-0005ps-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 18:47:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb5em-0005S3-00; Thu, 17 Jun 2004 18:46:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb5NV-0005qP-TY; Thu, 17 Jun 2004 18:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb5DS-0001Sg-8L for simple@megatron.ietf.org; Thu, 17 Jun 2004 18:18: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 SAA21485 for ; Thu, 17 Jun 2004 18:18:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb5DQ-0003nE-HF for simple@ietf.org; Thu, 17 Jun 2004 18:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb5BX-00038O-00 for simple@ietf.org; Thu, 17 Jun 2004 18:16:39 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bb59U-0002Gl-00 for simple@ietf.org; Thu, 17 Jun 2004 18:14:33 -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 i5HMCuLx011938; Thu, 17 Jun 2004 17:12:56 -0500 (CDT) Received: from [63.110.3.184] (dhcp184.dfw.dynamicsoft.com [63.110.3.184]) by DYN-TX-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KZRBQDPG; Thu, 17 Jun 2004 17:12:57 -0500 Message-ID: <40D21768.5010608@dynamicsoft.com> Date: Thu, 17 Jun 2004 17:12:56 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike Hammer wrote: > Would it not be possible to use just two binary flags and just make the > behavior of the receiving node a "Should not send DSN, MUST not send > response" with the sending node having a "MAY discard received DSN" or > is this a limited BW case for the sender? I would think that a relay > for BW-limited sender could also discard before a BW-limited link. The problem is that people envision doing things like sending administrative messages (e.g. "The IM system will be down from 5:00 to 7:00 pm for maintenance") to thousands or even hundreds of thousands of users, and they don't want negative responses for the ones that fail. > report-success=true send response?, send Pos-DSN report > report-success=false send response?, no Pos-DSN report > report-failures=true send response, send Neg-DSN report > report-failures=false no response, no report > report-failures=partial no response, may send report > applies to all devices. > > I'm still missing some details (? above). The "Report Success" flag never, ever, ever has an impact on whether transaction responses are sent. In fact, relays never need to even consider the value of the "Report Success" flag. It is processed by endpoints only. report-failures | Send Response? | Send report on failure? ----------------+----------------+------------------------ true | MUST | MUST false | MUST NOT | MUST NOT partial | MUST NOT | MAY /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 19:55:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27172 for ; Thu, 17 Jun 2004 19:55:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6iv-0005OP-VE for simple-archive@ietf.org; Thu, 17 Jun 2004 19:55:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6hy-00055G-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 19:54:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb6hU-0004mV-00; Thu, 17 Jun 2004 19:53:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6PQ-0000zs-Mr; Thu, 17 Jun 2004 19:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6D5-0005Z7-VA for simple@megatron.ietf.org; Thu, 17 Jun 2004 19: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 TAA25446 for ; Thu, 17 Jun 2004 19:22:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6D4-00029k-Gi for simple@ietf.org; Thu, 17 Jun 2004 19:22:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6C0-0001oZ-00 for simple@ietf.org; Thu, 17 Jun 2004 19:21:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bb6B5-0001CH-00 for simple@ietf.org; Thu, 17 Jun 2004 19:20:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2004 19:20:09 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5HNJh4w007716; Thu, 17 Jun 2004 19:19:43 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA49619; Thu, 17 Jun 2004 16:19:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20040617191710.06187008@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jun 2004 19:20:33 -0400 To: Adam Roach From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D21768.5010608@dynamicsoft.com> References: <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 05:12 PM 6/17/2004 -0500, Adam Roach wrote: >Mike Hammer wrote: >>Would it not be possible to use just two binary flags and just make the >>behavior of the receiving node a "Should not send DSN, MUST not send >>response" with the sending node having a "MAY discard received DSN" or is >>this a limited BW case for the sender? I would think that a relay for >>BW-limited sender could also discard before a BW-limited link. > >The problem is that people envision doing things like sending >administrative messages (e.g. "The IM system will be down from >5:00 to 7:00 pm for maintenance") to thousands or even hundreds >of thousands of users, and they don't want negative responses >for the ones that fail. Sounds like you would want to suppress successful responses too, but that is not an option for what is proposed. >>report-success=true send response?, send Pos-DSN report >>report-success=false send response?, no Pos-DSN report >>report-failures=true send response, send Neg-DSN report >>report-failures=false no response, no report >>report-failures=partial no response, may send report >>applies to all devices. >>I'm still missing some details (? above). > >The "Report Success" flag never, ever, ever has an impact >on whether transaction responses are sent. In fact, relays >never need to even consider the value of the "Report Success" >flag. It is processed by endpoints only. > >report-failures | Send Response? | Send report on failure? >----------------+----------------+------------------------ >true | MUST | MUST >false | MUST NOT | MUST NOT >partial | MUST NOT | MAY > >/a That clarifies one non-stated aspect, thanks. Time to wait for the official language to come out. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 17 20:04:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27833 for ; Thu, 17 Jun 2004 20:04:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6rq-0000Tv-Tg for simple-archive@ietf.org; Thu, 17 Jun 2004 20:04:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6r3-00006Z-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 20:03:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb6q4-0007I1-00; Thu, 17 Jun 2004 20:02:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6ii-0006rv-GQ; Thu, 17 Jun 2004 19:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6Ud-0002W2-Go for simple@megatron.ietf.org; Thu, 17 Jun 2004 19:40: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 TAA26544 for ; Thu, 17 Jun 2004 19:40:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6Ub-0000cY-Ov for simple@ietf.org; Thu, 17 Jun 2004 19:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6Tm-0000IL-00 for simple@ietf.org; Thu, 17 Jun 2004 19:39:35 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1Bb6T4-0007hu-00 for simple@ietf.org; Thu, 17 Jun 2004 19:38:50 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jun 2004 16:38:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jun 2004 16:38:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: delivery reports and transaction responses Date: Thu, 17 Jun 2004 16:38:16 -0700 Message-ID: Thread-Topic: [Simple] MSRP: delivery reports and transaction responses thread-index: AcRUvPonTx1BlJvzSZKWUH6eCzzcEwABqAww From: "Orit Levin" To: "Adam Roach" , "Mike Hammer" X-OriginalArrivalTime: 17 Jun 2004 23:38:02.0724 (UTC) FILETIME=[21996240:01C454C4] Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable A small modification to the "partial" row according to my interpretation: >report-failures | Send Response? | Send report on failure? > ----------------+----------------+------------------------ > true | MUST | MUST > false | MUST NOT | MUST NOT > partial | SHOULD NOT | SHOULD Orit. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Thursday, June 17, 2004 3:13 PM > To: Mike Hammer > Cc: pkyzivat@cisco.com; hisham.khartabil@nokia.com;=20 > cboulton@ubiquity.com; Ben Campbell; simple@ietf.org > Subject: Re: [Simple] MSRP: delivery reports and transaction responses >=20 > Mike Hammer wrote: > > Would it not be possible to use just two binary flags and just make=20 > > the behavior of the receiving node a "Should not send DSN, MUST not=20 > > send response" with the sending node having a "MAY discard received=20 > > DSN" or is this a limited BW case for the sender? I would=20 > think that=20 > > a relay for BW-limited sender could also discard before a=20 > BW-limited link. >=20 > The problem is that people envision doing things like sending=20 > administrative messages (e.g. "The IM system will be down=20 > from 5:00 to 7:00 pm for maintenance") to thousands or even=20 > hundreds of thousands of users, and they don't want negative=20 > responses for the ones that fail. >=20 > > report-success=3Dtrue send response?, send Pos-DSN report > > report-success=3Dfalse send response?, no Pos-DSN report > > report-failures=3Dtrue send response, send Neg-DSN report > > report-failures=3Dfalse no response, no report > > report-failures=3Dpartial no response, may send report > > applies to all devices. > >=20 > > I'm still missing some details (? above). >=20 > The "Report Success" flag never, ever, ever has an impact on=20 > whether transaction responses are sent. In fact, relays never=20 > need to even consider the value of the "Report Success" > flag. It is processed by endpoints only. >=20 > report-failures | Send Response? | Send report on failure? > ----------------+----------------+------------------------ > true | MUST | MUST > false | MUST NOT | MUST NOT > partial | MUST NOT | MAY >=20 > /a >=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-bounces@ietf.org Thu Jun 17 20:12:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28560 for ; Thu, 17 Jun 2004 20:12:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6zV-0003RG-Ey for simple-archive@ietf.org; Thu, 17 Jun 2004 20:12:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6yi-00037G-00 for simple-archive@ietf.org; Thu, 17 Jun 2004 20:11:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb6xw-0002ig-00; Thu, 17 Jun 2004 20:10:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6mp-00088i-4e; Thu, 17 Jun 2004 19:59:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6h1-00060q-0D for simple@megatron.ietf.org; Thu, 17 Jun 2004 19:53: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 TAA27137 for ; Thu, 17 Jun 2004 19:53:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb6gz-0004mR-HE for simple@ietf.org; Thu, 17 Jun 2004 19:53:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6g7-0004UC-00 for simple@ietf.org; Thu, 17 Jun 2004 19:52:19 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bb6ff-0004AU-00 for simple@ietf.org; Thu, 17 Jun 2004 19:51:51 -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 i5HNpCLx012012; Thu, 17 Jun 2004 18:51:12 -0500 (CDT) Received: from [63.110.3.184] (dhcp184.dfw.dynamicsoft.com [63.110.3.184]) by DYN-TX-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KZRBQDP0; Thu, 17 Jun 2004 18:51:12 -0500 Message-ID: <40D22E70.4080103@dynamicsoft.com> Date: Thu, 17 Jun 2004 18:51:12 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> <4.3.2.7.2.20040617191710.06187008@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040617191710.06187008@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mike Hammer wrote: > At 05:12 PM 6/17/2004 -0500, Adam Roach wrote: > >> ...people envision doing things like sending >> administrative messages (e.g. "The IM system will be down from >> 5:00 to 7:00 pm for maintenance") to thousands or even hundreds >> of thousands of users, and they don't want negative responses >> for the ones that fail. > > > Sounds like you would want to suppress successful responses too, but > that is not an option for what is proposed. Ummm... yes it is. Setting "report-failure" to "false" guarantees that you don't get any negative reports, and that you don't get any transaction responses (positive or negative). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 04:19:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05416 for ; Fri, 18 Jun 2004 04:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbEbI-0006JE-Qk for simple-archive@ietf.org; Fri, 18 Jun 2004 04:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEaF-0005xu-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 04:18:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbEZU-0005Zm-00; Fri, 18 Jun 2004 04:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEUS-0005Y5-RO; Fri, 18 Jun 2004 04:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbECA-0001Kg-05 for simple@megatron.ietf.org; Fri, 18 Jun 2004 03:53: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 DAA04137 for ; Fri, 18 Jun 2004 03:53:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbEC7-0005BO-LQ for simple@ietf.org; Fri, 18 Jun 2004 03:53:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEAP-0004gc-00 for simple@ietf.org; Fri, 18 Jun 2004 03:52:05 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BbE9J-0004KI-00 for simple@ietf.org; Fri, 18 Jun 2004 03:50:57 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I7og609475; Fri, 18 Jun 2004 10:50:42 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 10:50:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5I7oZAu007073; Fri, 18 Jun 2004 10:50:35 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00LjNRM2; Fri, 18 Jun 2004 10:50:34 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I7oYH18542; Fri, 18 Jun 2004 10:50:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 10:50:30 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] MSRP: delivery reports and transaction responses Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 18 Jun 2004 10:50:29 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C8F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: delivery reports and transaction responses thread-index: AcRUuIXG9G3IGbTkRdG08ka+utcdIgAUDh6Q To: , X-OriginalArrivalTime: 18 Jun 2004 07:50:30.0786 (UTC) FILETIME=[ED9DD620:01C45508] Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable And here is the table to report success: report-success | Send Response? | Send report on success? ----------------+----------------+------------------------ true | MUST NOT | MUST false | MUST NOT | MUST NOT /Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 18.June.2004 01:13 > To: Mike Hammer > Cc: Ben Campbell; pkyzivat@cisco.com; Khartabil Hisham > (Nokia-TP-MSW/Helsinki); cboulton@ubiquity.com; simple@ietf.org > Subject: Re: [Simple] MSRP: delivery reports and transaction responses >=20 >=20 > Mike Hammer wrote: > > Would it not be possible to use just two binary flags and=20 > just make the=20 > > behavior of the receiving node a "Should not send DSN, MUST=20 > not send=20 > > response" with the sending node having a "MAY discard=20 > received DSN" or=20 > > is this a limited BW case for the sender? I would think=20 > that a relay=20 > > for BW-limited sender could also discard before a BW-limited link. >=20 > The problem is that people envision doing things like sending > administrative messages (e.g. "The IM system will be down from > 5:00 to 7:00 pm for maintenance") to thousands or even hundreds > of thousands of users, and they don't want negative responses > for the ones that fail. >=20 > > report-success=3Dtrue send response?, send Pos-DSN report > > report-success=3Dfalse send response?, no Pos-DSN report > > report-failures=3Dtrue send response, send Neg-DSN report > > report-failures=3Dfalse no response, no report > > report-failures=3Dpartial no response, may send report > > applies to all devices. > >=20 > > I'm still missing some details (? above). >=20 > The "Report Success" flag never, ever, ever has an impact > on whether transaction responses are sent. In fact, relays > never need to even consider the value of the "Report Success" > flag. It is processed by endpoints only. >=20 > report-failures | Send Response? | Send report on failure? > ----------------+----------------+------------------------ > true | MUST | MUST > false | MUST NOT | MUST NOT > partial | MUST NOT | MAY >=20 > /a >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 04:27:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05700 for ; Fri, 18 Jun 2004 04:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbEis-0000tG-Sv for simple-archive@ietf.org; Fri, 18 Jun 2004 04:27:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEgn-0000UW-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 04:25:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbEfl-0007dg-00; Fri, 18 Jun 2004 04:24:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEVp-00069Y-II; Fri, 18 Jun 2004 04:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEEx-0001aY-BD for simple@megatron.ietf.org; Fri, 18 Jun 2004 03:56: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 DAA04346 for ; Fri, 18 Jun 2004 03:56:45 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbEEv-0006OB-59 for simple@ietf.org; Fri, 18 Jun 2004 03:56:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEE4-00064C-00 for simple@ietf.org; Fri, 18 Jun 2004 03:55:52 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BbEDP-0005jR-00 for simple@ietf.org; Fri, 18 Jun 2004 03:55:11 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I7t3614283; Fri, 18 Jun 2004 10:55:03 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 10:54:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5I7snKe020990; Fri, 18 Jun 2004 10:54:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Yzk9SZ; Fri, 18 Jun 2004 10:54:48 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I7slH00502; Fri, 18 Jun 2004 10:54:47 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 10:54:36 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RPID: what does tuple-type really mean? Date: Fri, 18 Jun 2004 10:54:36 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D19@esebe004.ntc.nokia.com> Thread-Topic: [Simple] RPID: what does tuple-type really mean? Thread-Index: AcRTpALSg2QVKZo6RNuO7C8shKpzwAAIwM0w To: , X-OriginalArrivalTime: 18 Jun 2004 07:54:36.0728 (UTC) FILETIME=[80359B80:01C45509] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > On Fri, 2004-06-11 at 11:44, ext Jonathan Rosenberg wrote: > ...snip... > > I think we are going to need to make sure that the > authorization stuff > > is aligned with the PIDF/RPID data models no matter what we > do. Part of > > my difficulties in wrapping up the authorization spec is > that we keep > > tripping on the "what is a tuple" issue in figuring out > what kind of > > functions to include in the authorization policies. >=20 > This is true. So from this point of view, it would be good > not to let PIDF restrict us in making things explicit.=20 >=20 > > You raise a good point on partial notifications. Using a separate=20 > > element also won't play well with that. I'd hate to force=20 > > things into tuples when they don't belong, just because partial=20 > > notifications doesnt know about anything but tuples. >=20 > I agree. >=20 > Mikko, what do you think about this? >From partial notification point of view it should be enough if these new elements would have similar ID attribute as tuples currently have and that they would share the same ID space. If there can be multiple occurrences of these new 'wrapper types' having similar ID as in tuple makes would be beneficial whether you use partial notifications or not.=20 - Mikko > Cheers, > Aki >=20 > > -Jonathan R. >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 04:55:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07093 for ; Fri, 18 Jun 2004 04:55:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbF9L-0002nu-Jz for simple-archive@ietf.org; Fri, 18 Jun 2004 04:55:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbF88-0002QI-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 04:53:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbF7B-0001jX-00; Fri, 18 Jun 2004 04:52:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEs2-0003VX-Qx; Fri, 18 Jun 2004 04:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEk1-0001AL-VE for simple@megatron.ietf.org; Fri, 18 Jun 2004 04:28: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 EAA05826 for ; Fri, 18 Jun 2004 04:28:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbEjz-0001Y4-IE for simple@ietf.org; Fri, 18 Jun 2004 04:28:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEjF-00017m-00 for simple@ietf.org; Fri, 18 Jun 2004 04:28:06 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BbEhg-0000Xb-00 for simple@ietf.org; Fri, 18 Jun 2004 04:26:28 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I8QQ213115; Fri, 18 Jun 2004 11:26:26 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 11:25:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5I8PwRq018038; Fri, 18 Jun 2004 11:25:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 007Df67d; Fri, 18 Jun 2004 11:23:51 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I8NiH03871; Fri, 18 Jun 2004 11:23:44 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 11:23:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 11:23: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] XCAP List Issue 3: Name and URI indices X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 18 Jun 2004 11:23:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C91@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP List Issue 3: Name and URI indices thread-index: AcRUVrj/vw3pthHNSlyfnklSNWXojgAtfAeg To: X-OriginalArrivalTime: 18 Jun 2004 08:23:40.0075 (UTC) FILETIME=[8F533FB0:01C4550D] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jonathan, I don't understand why someone would want to have 2 entries with the = same URI (by same I mean using the URI comparison rule). Why do you see = it as a possible feature? If you want it as a feature then it is much = simpler to use the name attribute as the key and the uri as a child = element of . I think you have already confused people by pointing out all those = comparison rules, and my reaction is that we should try to avoid them. /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 17.June.2004 13:18 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices >=20 >=20 > No comments on this? >=20 > -Jonathan R. >=20 > Jonathan Rosenberg wrote: >=20 > > Currently, the resource list format has two attributes for=20 > each .=20 > > The are the optional name, and mandatory URI parameter. The=20 > name exists=20 > > solely as an alternative index useful for XCAP selection of=20 > entries.=20 > > However, do we really need TWO indices? > >=20 > > The main concern around using the URI as an index is that URI=20 > > comparisons are more compelx than just string match, and if=20 > we use the=20 > > URI as an index for XCAP selection, the element would be=20 > selected based=20 > > on string equality (case sensitive, I believe). However,=20 > its possible=20 > > for two URI to be unequal by case sensitive string=20 > comparison, and equal=20 > > by URI equality. More interestingly, I think it is the case=20 > that if two=20 > > URI are equal by case sensitive string compare, then they=20 > will also be=20 > > equal by URI comparison rules. The implication is that I=20 > will always be=20 > > able to select the entry I want (i.e., there won't be=20 > ambiguity), but=20 > > the XCAP rules may allow me to have two entries that have=20 > the same URI=20 > > by URi equality rules, just because they differ by case=20 > sensitive string=20 > > comparison. > >=20 > > I don't think thats a particularly bad limitation (indeed,=20 > one might=20 > > even argue that its a feature). As such, I'd propose to=20 > drop the name=20 > > attribute entirely. > >=20 > > Note that the specification does need to also clarify that=20 > each =20 > > has to have a unique uri attribute amongst its siblings. It=20 > doesnt say=20 > > that now. This means that the server will reject, with a=20 > 409, a request=20 > > to add an if its uri attribute is not unique. > >=20 > > -Jonathan R. > >=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 > _______________________________________________ > 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-bounces@ietf.org Fri Jun 18 04:57:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07260 for ; Fri, 18 Jun 2004 04:57:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFBo-0003sg-IY for simple-archive@ietf.org; Fri, 18 Jun 2004 04:57:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFAv-0003Vn-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 04:56:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbFAD-0002w0-00; Fri, 18 Jun 2004 04:55:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEsr-0003fq-6e; Fri, 18 Jun 2004 04:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbEpi-0002mT-74 for simple@megatron.ietf.org; Fri, 18 Jun 2004 04:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06281 for ; Fri, 18 Jun 2004 04:34:44 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbEpf-0003m4-V2 for simple@ietf.org; Fri, 18 Jun 2004 04:34:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEoc-0003Nh-00 for simple@ietf.org; Fri, 18 Jun 2004 04:33:39 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BbEnb-0002wu-00 for simple@ietf.org; Fri, 18 Jun 2004 04:32:36 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I8WYN17540; Fri, 18 Jun 2004 11:32:34 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 11:32:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5I8WRMg013577; Fri, 18 Jun 2004 11:32:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 003jlJvE; Fri, 18 Jun 2004 11:31:52 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I8VmH26284; Fri, 18 Jun 2004 11:31:48 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 11:31:16 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP List Issue 4: List URI uniqueness X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 18 Jun 2004 11:31:15 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C92@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP List Issue 4: List URI uniqueness thread-index: AcRPv3jUQuGxHRmlRfO36pD0zvzlxgFTvdJA To: , X-OriginalArrivalTime: 18 Jun 2004 08:31:16.0614 (UTC) FILETIME=[9F719260:01C4550E] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I like this approach. /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 11.June.2004 14:48 > To: Simple WG > Subject: [Simple] XCAP List Issue 4: List URI uniqueness >=20 >=20 > The main purpose of the resource list XML schema is to define the=20 > resource lists that you can subscribe to using the SIP event=20 > extension=20 > for resource lists=20 > (http://www.watersprings.org/pub/id/draft-ietf-simple-event-li > st-04.txt). >=20 > This means that the SIP URI identifying each resource list=20 > needs to be=20 > unique on the server. Unfortunately, those URI exist buried=20 > within each=20 > resource list document. This makes it hard to, at the time a resource=20 > list is added or changed, check to see that the list URI is unique. >=20 > Similarly, when a resource list server (the SIP server handling=20 > SUBSCRIBE requests for the list) receives a SUBSCRIBE to a=20 > list, there=20 > isn't a clear document to go to that indicates the contents=20 > of that list. >=20 > In other words, the SIP URI for the resource lists is=20 > meaningful as an=20 > index, but it doesnt appear anywhere in the schemas as an index. >=20 > There are two solutions to this problem: >=20 > Approach I: Leave it alone. Let the XCAP servers maintain=20 > this index on=20 > their own. It does mean that that there isn't an easy way for the=20 > resource list server to fetch the contents of the list from the XCAP=20 > server in a standard way. >=20 > Approach II: We can define a new application usage, which is=20 > the actual=20 > set of resource list URIs you can subscribe to. There would=20 > be a single=20 > instance of this document for each user. That would contain=20 > the list of=20 > URIs defined by that user as subscribeable resource lists.=20 > For each URI,=20 > there would be a reference into their actual hierarchy of and=20 > s as defined by the current schema in the existing=20 > doc. For example: >=20 > > > http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/ > resource-lists/list[@name=3D=93co-workers=94] > > >=20 > We would, as a result of this, remove the "subscribeable"=20 > flag from the=20 > current schema, along with the URI attribute for the element. >=20 > In addition to there being a single instance of a document for each=20 > user, there would also be a single instance of a document for=20 > the entire=20 > server. This document would be in the global tree, readable only by=20 > resource lists servers. It basically contains the union of all of the=20 > documents for the individual users. This would allow a resource list=20 > server to do a single query to obtain the HTTP URI that defines the=20 > membership of the list. For example, if an RLS got a=20 > SUBSCRIBE request=20 > for sip:friends@example.com, it would do the following XCAP=20 > query to get=20 > the XCAP URI pointing to the membership: >=20 > GET=20 > http://xcap.server.com/xcap-root/list-of-lists/global/thelist/ > ~~/sip-uris/ > list[@uri=3D"sip:friends@example.com"] >=20 > and the 200 OK: >=20 > 200 OK > Content-Type: application/xml >=20 > > http://www.example.com/xcap/resource-lists/users/a/obuddies/ > =20 > resource-lists/list[@name=3D=93co-workers=94] > >=20 > Now it can do this: >=20 > GET http://www.example.com/xcap/resource-lists/users/a/obuddies/~~/ > resource-lists/list[@name=3D=93co-workers=94] >=20 > and get back: > 200 OK > Content-Type: application/xml >=20 > > > Bill Doe > > > > Joe Smith > > > Nancy Gross > > =20 > http://www.example.org/xcap/resource-lists/users/a/foo > > > >=20 >=20 > and the result is the list of URIs the RLS needs to subscribe to. >=20 >=20 > I really like approach 2. It clearly separates the SIP activities=20 > associated with a list, from the set of users that make up=20 > the list. It=20 > provides a concrete place where the index of buddy lists will=20 > live, both=20 > for each user and for all users. It seems to work better for ad-hoc=20 > lists two. The thing carried in the body of the SUBSCRIBE or=20 > INVITE or=20 > MESSAGE or whatever, which identifies the ad-hoc list, is only the=20 > structure set of users. The "subscribeable" flag would make=20 > no sense in=20 > that context, for example, and with this proposal, it would=20 > be removed. >=20 > Note that a change to the list for a single user would need to be=20 > automatically reflected in the global list by the server. >=20 > I'd propose making this change. I think we need to define both=20 > application usages up front, since we can't satisfy our driving=20 > requirement (define a way to create buddy lists for SIP resource list=20 > subscriptions) without both. I would do them both in the same=20 > document=20 > however. >=20 > Comments? >=20 > Thanks, > Jonathan R. > --=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-bounces@ietf.org Fri Jun 18 05:05:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07739 for ; Fri, 18 Jun 2004 05:05:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFJf-0006lI-NI for simple-archive@ietf.org; Fri, 18 Jun 2004 05:05:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFIg-0006PC-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 05:04:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbFHk-0005jN-00; Fri, 18 Jun 2004 05:03:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFCR-0007kN-BP; Fri, 18 Jun 2004 04:58:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbF0H-0004lr-3t for simple@megatron.ietf.org; Fri, 18 Jun 2004 04:45: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 EAA06749 for ; Fri, 18 Jun 2004 04:45:39 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbF0E-0007T3-Qi for simple@ietf.org; Fri, 18 Jun 2004 04:45:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbEzJ-0006rO-00 for simple@ietf.org; Fri, 18 Jun 2004 04:44:42 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BbEyY-0006XM-00 for simple@ietf.org; Fri, 18 Jun 2004 04:43:54 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I8hr628573; Fri, 18 Jun 2004 11:43:53 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 11:43:50 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5I8hoaP024781; Fri, 18 Jun 2004 11:43:50 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00CpSFGE; Fri, 18 Jun 2004 11:43:47 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5I8hlH03718; Fri, 18 Jun 2004 11:43:47 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 11:43:48 +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] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 18 Jun 2004 11:43:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C93@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops thread-index: AcRUWLAJ/Sv0ii0GTs+ZuXL1krxz+QAtlCcA To: X-OriginalArrivalTime: 18 Jun 2004 08:43:48.0627 (UTC) FILETIME=[5FADA630:01C45510] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 17.June.2004 13:47 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP Issue 7 Interim Summary: uniqueness in > intermediatehops >=20 >=20 > inline. >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >> -----Original Message----- From: simple-bounces@ietf.org=20 > >> [mailto:simple-bounces@ietf.org]On Behalf Of ext Jonathan Rosenberg > >> Sent: 10.June.2004 10:12 To: Simple WG Subject: [Simple] XCAP > >> Issue 7 Interim Summary: uniqueness in intermediatehops > >>=20 > >>=20 > >> This is an issue raised by Joel and discussed on the list. The > >> problem was whether or not we would require the URI to select a=20 > >> unique element at each hop of its evaluation, or just make sure the > >> final result of selection was unique. > >>=20 > >> If you are implementing XCAP without an XPATH library, this is a > >> really nice feature to have. There is code and computational=20 > >> complexity if its not there. If you have an XPATH library, its a > >> constraint that you need to explicitly verify outside of the xpath > >> library, since XPATH does allow non-uniqueness at each hop. > >>=20 > >> There were continuing objections to the complexity introduced if > >> each hop is not unique. As such, there was consensus on the > >> uniqueness requirement. > >>=20 > >> However, Henning had a proposal to take this a step further. His=20 > >> proposal was that we could constrain XCAP so that at each step, you > >> were selecting an element based on a unique index that was declared > >> by the application usage to be unique. This way, you couldn't even > >> ever have an expression which selected multiple things at each > >> step. Here's an example to explain. Lets say we've got a schema > >> that has a parent element called , and can have one or > >> more children, each named . So, the following is a valid > >> document: > >>=20 > >> > >>=20 > >> And thus, the expression "foo/bar" selects the element, and > >> also gives you a single element at each step. Thus, it would be > >> valid. However, in Hennings proposal, this expression would be=20 > >> illegal, since it might be the case that is not unique, and > >> thus it could be the case that tbe expression "foo/bar" does not > >> resolve to something unique. In such a case, the schema would have > >> to mandate that each bar element have an attribute called "id" (for > >> example), and that the application usage would mandate that this > >> attribute be unique amongst all siblings. If you do that, then you > >> can be guaranteed that the expression: > >>=20 > >> foo/bar[@id=3D"223"] > >>=20 > >> is unique. It may not point to anything, but if it does, it points > >> to only one element. > >>=20 > >> Henning, if I have mis-interpreted your proposal, let me know. > >>=20 > >> This proposal was further refined. The idea was that an element > >> needs to have a unique index only if it can appear more than once > >> in the document. If it can appear only once, you don't need to=20 > >> define a unique attribute for it. > >>=20 > >> Upon further consideration, I concluded that the refined proposal > >> was not a good idea. The objective of what Henning was proposing is > >> that a server could look at the URI, and without needing to know > >> the schema or even the instance document, determine whether the URI > >> resolved to something unique. Of course, it could still resolve to > >> nothing if any one of the indices didn't exist in the instance > >> document. With the refined proposal, the server would need to know > >> the schema to determine whether the URI was unique. > >=20 > >=20 > > No it doesn't. The server can still do the dynamic checking of the > > instance document. Having refined proposal will aid in eliminating > > the possibility of failure. >=20 > Once you have committed to do the dynamic checking of the=20 > document, why=20 > not just deal with the failure case? You already need to deal=20 > with the=20 > failure case that there may be no instances of an element,=20 > even though=20 > one is requested in a GET. Why is that harder than dealing=20 > with the case=20 > that there are more than one? Why deal with the failure case when we can eliminate it? >=20 > If you try and eliminate it by introducing rules into the=20 > structure of=20 > the document (that is, impose rules on the schemas for XCAP managed=20 > documents), you make it so that xcap can NEVER be used to manage=20 > documents whose schema doesn't match the requirements. We already have restrictions on what the XML schema should look like to = be XCAP friendly. This is just another one. >=20 >=20 > >=20 > > eg: if we have > >=20 > > > >=20 > > then /foo/bar/baz expression is not unique at every step and > > therefore I can never ever modify . >=20 > Right. In none of the proposals on the table would you be=20 > able to modify=20 > baz if a document looks like this. So the proposal was to disallow such schema design. >=20 > >=20 > > If we define that "an element needs to have a unique index=20 > only if it > > can appear more than once in the document. If it can appear only > > once, you don't need to define a unique attribute for it", then the > > server can still do the dynamic checking (if it does not trust the > > client) and it enables the client to modify some parts of the > > instance document that are otherwise unmodifiable. >=20 > I don't understand. None of the proposals differ in terms of=20 > making it=20 > possible to modify something that isn't modifiable in one of=20 > the other=20 > proposals. btw, can be modified using positional selection, like this: /foo/bar[1]/baz this, of course, requires the client to have a copy of the XML document. >=20 > In the technique you are advocating, we would introduce this=20 > rule that=20 > an element can appear once in a doc, and if it appears more=20 > than once,=20 > has to have a unique index. This can be enforced by mandating that=20 > XCAP-managebale documents have to have schemas with this=20 > constraint. I=20 > think that is too limiting. Perhaps you are instead=20 > advocating that we=20 > don't introduce this constraint into the schema, but rather, instance=20 > documents. I still think thats too limiting. We may have=20 > documents that=20 > have two elements with the same name and no unique=20 > attributes, but there=20 > isn't a need to modify at that level; you would only be able=20 > to modify=20 > the document by addressing elements that are ancestors of the pair.=20 > Thats fine. So, I'm saying, allow documents to look this way,=20 > but you'll=20 > get an error if you try and address below this point in the document=20 > where the pair exists. Of course, if there is only one=20 > element with the=20 > name in the document, you can address deeper. In your=20 > proposal, you are=20 > just trying to eliminate the case where a document ever has=20 > two elements=20 > with the same name and non-unique attributes; in the approach=20 > I prefer,=20 > you allow the case but don't allow addressing below that level. In=20 > neither case can you address into a document below a set of=20 > non-uniquely-identifiable elements. >=20 > I think its fine to have a guideline which recommends that a client=20 > needs to use unique attributes when creating documents where=20 > it wants to=20 > address those elements or below. But, this is nothing more than a=20 > guideline. Ok, I think I'm fine with it just being a guideline. /Hisham >=20 > -Jonathan R. >=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 05:45:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09884 for ; Fri, 18 Jun 2004 05:45:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFwJ-0005tM-21 for simple-archive@ietf.org; Fri, 18 Jun 2004 05:45:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFvM-0005Xx-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 05:44:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbFuU-0004sI-00; Fri, 18 Jun 2004 05:43:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFn4-00080S-CE; Fri, 18 Jun 2004 05:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFhr-0006lc-GO for simple@megatron.ietf.org; Fri, 18 Jun 2004 05:30: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 FAA09117 for ; Fri, 18 Jun 2004 05:30:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFhp-0000NF-4f for simple@ietf.org; Fri, 18 Jun 2004 05:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFh2-00001O-00 for simple@ietf.org; Fri, 18 Jun 2004 05:29:52 -0400 Received: from epact.se ([192.36.138.128]) by ietf-mx with esmtp (Exim 4.12) id 1BbFgR-0007Ij-00 for simple@ietf.org; Fri, 18 Jun 2004 05:29:15 -0400 Received: from krypton (krypton.epact.se [192.36.138.36]) by epact.se (8.12.11/8.12.10) with SMTP id i5I9Sjk4012808 for ; Fri, 18 Jun 2004 11:28:46 +0200 From: "helei" To: "Simple mailinglist" Subject: [SIMPLE] Authorization of resource list back-end subscriptions Date: Fri, 18 Jun 2004 11:32:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The draft-ietf-simple-event-list-04 (expired, yes, but I hope it will be revitalized soon) states that a resource list may have several subscribers. It also states that the _RLS_ act as subscriber for the back-end subscriptions to any non-local resources on the list. This makes me wonder: - How can the non-local resources authorize the actual list subscribers (those subscribing to the resource list)? The Watcher-info document would only hold the RLS as a subscriber? - Why prohibit reuse of information from one back-end subscription when the actual subscription is not associated with the list subscriber? Shouldn't it be the _resource-list_ that acts as subscriber? Best regards, Henrik Leion _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 08:28:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17010 for ; Fri, 18 Jun 2004 08:28:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbITf-0004Kb-L0 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:28:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbISq-0003u8-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:27:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbIQv-00032N-00; Fri, 18 Jun 2004 08:25:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIJv-0002gn-9n; Fri, 18 Jun 2004 08:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbI9v-0000Fq-Cf for simple@megatron.ietf.org; Fri, 18 Jun 2004 08:07: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 IAA15676 for ; Fri, 18 Jun 2004 08:07:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbI9u-000421-Tg for simple@ietf.org; Fri, 18 Jun 2004 08:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbI82-0003dx-00 for simple@ietf.org; Fri, 18 Jun 2004 08:05:54 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BbI7F-0002w9-00 for simple@ietf.org; Fri, 18 Jun 2004 08:05:05 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5IC4V016373 for ; Fri, 18 Jun 2004 07:04:32 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Jun 2004 13:04:30 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C61410B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: helei , Simple mailinglist Subject: RE: [SIMPLE] Authorization of resource list back-end subscription s Date: Fri, 18 Jun 2004 13:04:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I am sure the SIMPLE chairs will support me in assuring you that draft-ietf-simple-event-list-04.txt is not expired. In has reached the stage of submission to IESG for review, and therefore in that special state where drafts DO NOT expire after 6 months. regards Keith > -----Original Message----- > From: helei [mailto:helei@epact.se] > Sent: 18 June 2004 10:32 > To: Simple mailinglist > Subject: [SIMPLE] Authorization of resource list back-end > subscriptions > > > The draft-ietf-simple-event-list-04 (expired, yes, but I hope > it will be > revitalized soon) states that a resource list may have > several subscribers. > It also states that the _RLS_ act as subscriber for the back-end > subscriptions to any non-local resources on the list. > > This makes me wonder: > - How can the non-local resources authorize the actual list > subscribers > (those subscribing to the resource list)? The Watcher-info > document would > only hold the RLS as a subscriber? > - Why prohibit reuse of information from one back-end > subscription when the > actual subscription is not associated with the list subscriber? > > Shouldn't it be the _resource-list_ that acts as subscriber? > > Best regards, > Henrik Leion > > > _______________________________________________ > 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-bounces@ietf.org Fri Jun 18 08:35:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17252 for ; Fri, 18 Jun 2004 08:35:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIb0-0007J9-84 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:35:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIZz-0006w9-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:34:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbIZ3-0006DQ-00; Fri, 18 Jun 2004 08:33:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbITB-00056a-Pf; Fri, 18 Jun 2004 08:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbINT-0003Nf-5B for simple@megatron.ietf.org; Fri, 18 Jun 2004 08:21: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 IAA16664 for ; Fri, 18 Jun 2004 08:21:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbINS-0002Fh-M7 for simple@ietf.org; Fri, 18 Jun 2004 08:21:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIMV-0001tB-00 for simple@ietf.org; Fri, 18 Jun 2004 08:20:51 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BbILa-00018n-00 for simple@ietf.org; Fri, 18 Jun 2004 08:19:54 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5ICJfbo026501; Fri, 18 Jun 2004 08:19:41 -0400 (EDT) Message-ID: <40D2DDC9.5040502@dynamicsoft.com> Date: Fri, 18 Jun 2004 08:19:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C91@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C91@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Jonathan, > > I don't understand why someone would want to have 2 entries with the > same URI (by same I mean using the URI comparison rule). Why do you > see it as a possible feature? I really don't think its important. We could do it, was all I was saying. > If you want it as a feature then it is > much simpler to use the name attribute as the key and the uri as a > child element of . > > I think you have already confused people by pointing out all those > comparison rules, and my reaction is that we should try to avoid > them. Sorry for being confusing. The simple point is this - using the URI as an index works, since case sensitive string comparison is OK. Let me point out a real world situation that relates to this topic. Lets say you and I are both editing the resource list for the SIMPLE participants. We both independently notice that robert is not on the list somehow. So, you go to do an insert, and you insert thusly: PUT http://blah-blah/entry[@uri="sip:rsparks@dynamicsoft.com"] then, I do an insertion, but using DYNAMICSOFT.COM: PUT http://blah-blah/entry[@uri="sip:rsparks@DYNAMICSOFT.COM"] now, in this case, the URI are equal by URI comparison, unequal by case sensitive string compare. So, both get inserted. Now, you might argue that I've just proven that we should use a name attribute, since if we had a name attribute that was the same for all equivalent forms of the URI, we wouldn't have this problem. Thats true, but, to compute such an attribute, you'd need to define a function that takes a URI as an input, and canonicalizes it in such a way that all equivalent URI would canonicalize to the same result. For an AOR that doesnt contain URI parameters (which is what we're concerned about), a simple toLower() on the domain part will do the job. Of course, once you do that, you have a way to use a URI as an index that doesnt have this ambiguity problem as above. So, you may as well just use that resulting URI as the index, and you're right back to where we started from. *So*, I would suggest that: -- we use the "uri" as an index -- we recommend canonicalizing the URI before using, per above This has the same benefits of a separate "name" index, with the same implementation cost, but with smaller data size and it avoids repeating information. -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-bounces@ietf.org Fri Jun 18 08:39:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17393 for ; Fri, 18 Jun 2004 08:39:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIex-00010E-Qb for simple-archive@ietf.org; Fri, 18 Jun 2004 08:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIeD-0000d8-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:39:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbIdZ-0000Fu-00; Fri, 18 Jun 2004 08:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIWp-0005zm-CC; Fri, 18 Jun 2004 08:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbISH-0004iL-50 for simple@megatron.ietf.org; Fri, 18 Jun 2004 08:26: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 IAA16765 for ; Fri, 18 Jun 2004 08:26:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbISG-0003qO-Ln for simple@ietf.org; Fri, 18 Jun 2004 08:26:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIQO-00031U-00 for simple@ietf.org; Fri, 18 Jun 2004 08:24:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BbIOf-0002Gv-00 for simple@ietf.org; Fri, 18 Jun 2004 08:23:05 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5ICMrbo026504; Fri, 18 Jun 2004 08:22:54 -0400 (EDT) Message-ID: <40D2DE8A.8010700@dynamicsoft.com> Date: Fri, 18 Jun 2004 08:22:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] XCAP List Issue 2: Whither URI References: <40C99509.1030400@dynamicsoft.com> <40CD4FA1.9030305@nokia.com> <40D16F98.6000404@dynamicsoft.com> <40D188E0.2030304@nokia.com> In-Reply-To: <40D188E0.2030304@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > Jonathan, > > I think I had in my mind the URI representing the list and not each of > the entries as I said in my previous e-mail, my apologies if I missled > you. The URI representing the list is not visible in the schema (I > believe), so my comment is not applicable. Currently, it is in the schema. Regarding issue 2, it would move to a separate document, with a separate schema, though it would still be a URI attribute (to allow it to be used as an index). > > Also, can you provide an example of the XML document? The draft does not > contain any. This will help me in understanding the schema. Sure. My apologies. I'll be doing a rev of that doc as soon as we settle on the issues, and I think we're just about there. Here is an example doc that is compliant to the current schema in -02: Bill Doe Joe Smith Nancy Gross http://www.example.org/xcap/resource-lists/users/a/foo HTH, 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-bounces@ietf.org Fri Jun 18 08:54:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17945 for ; Fri, 18 Jun 2004 08:54:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIst-0006OM-FZ for simple-archive@ietf.org; Fri, 18 Jun 2004 08:54:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIro-0005y0-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:53:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbIqr-0005QV-00; Fri, 18 Jun 2004 08:52:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIf7-0007tW-TN; Fri, 18 Jun 2004 08:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIb4-0006dd-MW for simple@megatron.ietf.org; Fri, 18 Jun 2004 08:35: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 IAA17283 for ; Fri, 18 Jun 2004 08:35:53 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIb4-0007Je-6E for simple@ietf.org; Fri, 18 Jun 2004 08:35:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIa7-0006xB-00 for simple@ietf.org; Fri, 18 Jun 2004 08:34:56 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BbIZc-0006aK-00 for simple@ietf.org; Fri, 18 Jun 2004 08:34:25 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ICY6618275; Fri, 18 Jun 2004 15:34:06 +0300 (EET DST) X-Scanned: Fri, 18 Jun 2004 15:34:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5ICY0PH020582; Fri, 18 Jun 2004 15:34:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 0081DcTB; Fri, 18 Jun 2004 15:33:55 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ICXsH01875; Fri, 18 Jun 2004 15:33:54 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Jun 2004 15:33:54 +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] XCAP List Issue 3: Name and URI indices X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 18 Jun 2004 15:33:54 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP List Issue 3: Name and URI indices thread-index: AcRVLtCxcp+x6Rn3QPy7Q1eMelcIoAAAS1Ag To: X-OriginalArrivalTime: 18 Jun 2004 12:33:54.0361 (UTC) FILETIME=[84897A90:01C45530] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I'm fine with that, as long as we can provide enough text to eliminate = the possibility of having the same resource twice in a list. Perhaps = both a URI comparison and string comparison together need to be = performed (or mandate canonicalisation). I really don't want the same resource to end up on the list more than = once causing multiple subscriptions to the same resource. Thanks, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 18.June.2004 15:19 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > > Jonathan, > >=20 > > I don't understand why someone would want to have 2 entries with the > > same URI (by same I mean using the URI comparison rule). Why do you > > see it as a possible feature? >=20 > I really don't think its important. We could do it, was all I=20 > was saying. >=20 >=20 > > If you want it as a feature then it is > > much simpler to use the name attribute as the key and the uri as a > > child element of . > >=20 > > I think you have already confused people by pointing out all those > > comparison rules, and my reaction is that we should try to avoid > > them. >=20 > Sorry for being confusing. >=20 > The simple point is this - using the URI as an index works,=20 > since case=20 > sensitive string comparison is OK. >=20 > Let me point out a real world situation that relates to this topic. >=20 > Lets say you and I are both editing the resource list for the SIMPLE=20 > participants. We both independently notice that robert is not on the=20 > list somehow. So, you go to do an insert, and you insert thusly: >=20 > PUT http://blah-blah/entry[@uri=3D"sip:rsparks@dynamicsoft.com"] >=20 > then, I do an insertion, but using DYNAMICSOFT.COM: >=20 > PUT http://blah-blah/entry[@uri=3D"sip:rsparks@DYNAMICSOFT.COM"] >=20 > now, in this case, the URI are equal by URI comparison,=20 > unequal by case=20 > sensitive string compare. So, both get inserted. >=20 > Now, you might argue that I've just proven that we should use a name=20 > attribute, since if we had a name attribute that was the same for all=20 > equivalent forms of the URI, we wouldn't have this problem.=20 > Thats true,=20 > but, to compute such an attribute, you'd need to define a=20 > function that=20 > takes a URI as an input, and canonicalizes it in such a way that all=20 > equivalent URI would canonicalize to the same result. For an AOR that=20 > doesnt contain URI parameters (which is what we're concerned=20 > about), a=20 > simple toLower() on the domain part will do the job. Of=20 > course, once you=20 > do that, you have a way to use a URI as an index that doesnt=20 > have this=20 > ambiguity problem as above. So, you may as well just use that=20 > resulting=20 > URI as the index, and you're right back to where we started from. >=20 > *So*, I would suggest that: >=20 > -- we use the "uri" as an index > -- we recommend canonicalizing the URI before using, per above >=20 > This has the same benefits of a separate "name" index, with the same=20 > implementation cost, but with smaller data size and it avoids=20 > repeating=20 > information. >=20 > -Jonathan R. >=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 08:55:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18068 for ; Fri, 18 Jun 2004 08:55:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIuT-0007As-Ow for simple-archive@ietf.org; Fri, 18 Jun 2004 08:55:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbItZ-0006n9-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:55:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbIsx-0006Li-00; Fri, 18 Jun 2004 08:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIk8-0000Gr-F6; Fri, 18 Jun 2004 08:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIdr-0007cT-8z for simple@megatron.ietf.org; Fri, 18 Jun 2004 08:38: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 IAA17313 for ; Fri, 18 Jun 2004 08:38:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIdq-0000bf-SB for simple@ietf.org; Fri, 18 Jun 2004 08:38:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIcr-0000EW-00 for simple@ietf.org; Fri, 18 Jun 2004 08:37:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BbIbt-0007K9-00 for simple@ietf.org; Fri, 18 Jun 2004 08:36:45 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5ICaYbo026517; Fri, 18 Jun 2004 08:36:34 -0400 (EDT) Message-ID: <40D2E1BE.9080707@dynamicsoft.com> Date: Fri, 18 Jun 2004 08:36:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops References: <2038BCC78B1AD641891A0D1AE133DBB701797C93@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C93@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >> >>Once you have committed to do the dynamic checking of the >>document, why >>not just deal with the failure case? You already need to deal >>with the >>failure case that there may be no instances of an element, >>even though >>one is requested in a GET. Why is that harder than dealing >>with the case >>that there are more than one? > > > Why deal with the failure case when we can eliminate it? Because eliminating it will require more implementation complexity than not. To eliminate the real-time check, the xcap implementation needs additional meta-data about the schema, which it can use to verify that, upon receipt, the URI is using a unique index at each hop. Implementing such a meta-data feature will be more work than just checking the document instance, since you need to go through the document instance ANYWAY. >>If you try and eliminate it by introducing rules into the >>structure of >>the document (that is, impose rules on the schemas for XCAP managed >>documents), you make it so that xcap can NEVER be used to manage >>documents whose schema doesn't match the requirements. > > > We already have restrictions on what the XML schema should look like to be XCAP friendly. This is just another one. No, there is a HUGE difference. The xcap guidelines are just that - guidelines. You can still manage any XML compliant document with xcap; you may just end up reading/writing the whole thing at once. But it works. Thats radically different from saying that XCAP can ONLY manage documents whose schemas meet this criteria. If that is the case, we could not ever manage things like CPL documents, which dont have this property of uniqueness at each element. >>I don't understand. None of the proposals differ in terms of >>making it >>possible to modify something that isn't modifiable in one of >>the other >>proposals. > > > btw, can be modified using positional selection, like this: > > /foo/bar[1]/baz > > this, of course, requires the client to have a copy of the XML document. Yes, this is possible. > > >>In the technique you are advocating, we would introduce this >>rule that >>an element can appear once in a doc, and if it appears more >>than once, >>has to have a unique index. This can be enforced by mandating that >>XCAP-managebale documents have to have schemas with this >>constraint. I >>think that is too limiting. Perhaps you are instead >>advocating that we >>don't introduce this constraint into the schema, but rather, instance >>documents. I still think thats too limiting. We may have >>documents that >>have two elements with the same name and no unique >>attributes, but there >>isn't a need to modify at that level; you would only be able >>to modify >>the document by addressing elements that are ancestors of the pair. >>Thats fine. So, I'm saying, allow documents to look this way, >>but you'll >>get an error if you try and address below this point in the document >>where the pair exists. Of course, if there is only one >>element with the >>name in the document, you can address deeper. In your >>proposal, you are >>just trying to eliminate the case where a document ever has >>two elements >>with the same name and non-unique attributes; in the approach >>I prefer, >>you allow the case but don't allow addressing below that level. In >>neither case can you address into a document below a set of >>non-uniquely-identifiable elements. >> >>I think its fine to have a guideline which recommends that a client >>needs to use unique attributes when creating documents where >>it wants to >>address those elements or below. But, this is nothing more than a >>guideline. > > > Ok, I think I'm fine with it just being a guideline. OK, great. -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-bounces@ietf.org Fri Jun 18 08:59:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18196 for ; Fri, 18 Jun 2004 08:59:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIyF-0000vC-8G for simple-archive@ietf.org; Fri, 18 Jun 2004 08:59:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIxL-0000B5-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 08:58:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbIvh-0007Qq-00; Fri, 18 Jun 2004 08:57:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIsT-0002fN-MY; Fri, 18 Jun 2004 08:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIhx-0008ME-08 for simple@megatron.ietf.org; Fri, 18 Jun 2004 08:43: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 IAA17596 for ; Fri, 18 Jun 2004 08:42:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIhw-00028X-D5 for simple@ietf.org; Fri, 18 Jun 2004 08:43:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIh9-0001V0-00 for simple@ietf.org; Fri, 18 Jun 2004 08:42:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BbIg2-000119-00 for simple@ietf.org; Fri, 18 Jun 2004 08:41:02 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5ICeobo026523; Fri, 18 Jun 2004 08:40:50 -0400 (EDT) Message-ID: <40D2E2C0.7040401@dynamicsoft.com> Date: Fri, 18 Jun 2004 08:40:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I'm fine with that, as long as we can provide enough text to > eliminate the possibility of having the same resource twice in a > list. Perhaps both a URI comparison and string comparison together > need to be performed (or mandate canonicalisation). I think we should define the canonicalization, and put it at SHOULD strength. > > I really don't want the same resource to end up on the list more than > once causing multiple subscriptions to the same resource. Generally, it doesnt make sense. But, there may be some reason why its desired. Nothing breaks if you do it, I dont think, so the canonicalization can be at SHOULD strength, not MUST. -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-bounces@ietf.org Fri Jun 18 10:26:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26597 for ; Fri, 18 Jun 2004 10:26:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKJp-00029u-NS for simple-archive@ietf.org; Fri, 18 Jun 2004 10:26:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKIk-0001gx-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 10:25:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbKGq-0000We-00; Fri, 18 Jun 2004 10:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbK2U-0002bm-1n; Fri, 18 Jun 2004 10:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbJkO-0000YR-79 for simple@megatron.ietf.org; Fri, 18 Jun 2004 09:49: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 JAA21587 for ; Fri, 18 Jun 2004 09:49:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbJkN-0005Ut-KV for simple@ietf.org; Fri, 18 Jun 2004 09:49:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbJhR-0004VJ-00 for simple@ietf.org; Fri, 18 Jun 2004 09:46:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BbJf3-0003Ph-00 for simple@ietf.org; Fri, 18 Jun 2004 09:44:05 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2004 09:49:16 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5IDhWhD007839; Fri, 18 Jun 2004 09:43:32 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA77718; Fri, 18 Jun 2004 06:43:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20040618094023.02e43f08@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jun 2004 09:44:23 -0400 To: Adam Roach From: Mike Hammer Subject: Re: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <40D22E70.4080103@dynamicsoft.com> References: <4.3.2.7.2.20040617191710.06187008@cia.cisco.com> <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617114102.00b50c50@cia.cisco.com> <4.3.2.7.2.20040617120910.00b59960@cia.cisco.com> <4.3.2.7.2.20040617191710.06187008@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 06:51 PM 6/17/2004 -0500, Adam Roach wrote: >Mike Hammer wrote: > >>At 05:12 PM 6/17/2004 -0500, Adam Roach wrote: >> >>>...people envision doing things like sending >>>administrative messages (e.g. "The IM system will be down from >>>5:00 to 7:00 pm for maintenance") to thousands or even hundreds >>>of thousands of users, and they don't want negative responses >>>for the ones that fail. >> >> >>Sounds like you would want to suppress successful responses too, but that >>is not an option for what is proposed. > >Ummm... yes it is. Setting "report-failure" to "false" guarantees that you >don't get any negative reports, and that you don't get any transaction >responses (positive or negative). > >/a Now, you've totally confused me. My understanding was that the report-failure flag governed the behavior of the negative reports and negative responses, while the report-success flag governed the positive reports, but only for the endpoints and not for the positive responses; where the sending of the positive transaction response was not governed by either flag. This is why I have decided to withdraw until I see the official description. The answers from this email thread have gotten me closer to understanding, but have not been completely consistent. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 10:31:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27092 for ; Fri, 18 Jun 2004 10:31:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKPF-0004OI-KF for simple-archive@ietf.org; Fri, 18 Jun 2004 10:31:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKO0-0003q6-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 10:30:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbKN0-0003N1-00; Fri, 18 Jun 2004 10:29:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbK2y-0002ux-AI; Fri, 18 Jun 2004 10:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbJmo-0001YC-B6 for simple@megatron.ietf.org; Fri, 18 Jun 2004 09:52: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 JAA21832 for ; Fri, 18 Jun 2004 09:52:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbJmn-0006Qk-NZ for simple@ietf.org; Fri, 18 Jun 2004 09:52:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbJkD-0005S2-00 for simple@ietf.org; Fri, 18 Jun 2004 09:49:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BbJh2-000422-00 for simple@ietf.org; Fri, 18 Jun 2004 09:46:08 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2004 09:51:20 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5IDjZ4w002056; Fri, 18 Jun 2004 09:45:36 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-248.cisco.com [64.100.229.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAA77847; Fri, 18 Jun 2004 06:45:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20040618094544.02e41098@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jun 2004 09:46:26 -0400 To: hisham.khartabil@nokia.com, From: Mike Hammer Subject: RE: [Simple] MSRP: delivery reports and transaction responses In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C8F@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pkyzivat@cisco.com, cboulton@ubiquity.com, bcampbell@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:50 AM 6/18/2004 +0300, hisham.khartabil@nokia.com wrote: >And here is the table to report success: > >report-success | Send Response? | Send report on success? >----------------+----------------+------------------------ >true | MUST NOT | MUST >false | MUST NOT | MUST NOT From below: "The "Report Success" flag never, ever, ever has an impact > on whether transaction responses are sent." Why is there a response column here? Mike >/Hisham > > > -----Original Message----- > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: 18.June.2004 01:13 > > To: Mike Hammer > > Cc: Ben Campbell; pkyzivat@cisco.com; Khartabil Hisham > > (Nokia-TP-MSW/Helsinki); cboulton@ubiquity.com; simple@ietf.org > > Subject: Re: [Simple] MSRP: delivery reports and transaction responses > > > > > > Mike Hammer wrote: > > > Would it not be possible to use just two binary flags and > > just make the > > > behavior of the receiving node a "Should not send DSN, MUST > > not send > > > response" with the sending node having a "MAY discard > > received DSN" or > > > is this a limited BW case for the sender? I would think > > that a relay > > > for BW-limited sender could also discard before a BW-limited link. > > > > The problem is that people envision doing things like sending > > administrative messages (e.g. "The IM system will be down from > > 5:00 to 7:00 pm for maintenance") to thousands or even hundreds > > of thousands of users, and they don't want negative responses > > for the ones that fail. > > > > > report-success=true send response?, send Pos-DSN report > > > report-success=false send response?, no Pos-DSN report > > > report-failures=true send response, send Neg-DSN report > > > report-failures=false no response, no report > > > report-failures=partial no response, may send report > > > applies to all devices. > > > > > > I'm still missing some details (? above). > > > > The "Report Success" flag never, ever, ever has an impact > > on whether transaction responses are sent. In fact, relays > > never need to even consider the value of the "Report Success" > > flag. It is processed by endpoints only. > > > > report-failures | Send Response? | Send report on failure? > > ----------------+----------------+------------------------ > > true | MUST | MUST > > false | MUST NOT | MUST NOT > > partial | MUST NOT | MAY > > > > /a > > > >_______________________________________________ >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-bounces@ietf.org Fri Jun 18 10:44:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28253 for ; Fri, 18 Jun 2004 10:44:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKbz-0002Ga-KN for simple-archive@ietf.org; Fri, 18 Jun 2004 10:44:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKb2-0001sy-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 10:44:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbKa8-00017d-00; Fri, 18 Jun 2004 10:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKPh-0004En-5M; Fri, 18 Jun 2004 10:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKBn-0007O0-82 for simple@megatron.ietf.org; Fri, 18 Jun 2004 10:17: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 KAA25864 for ; Fri, 18 Jun 2004 10:17:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKBm-00071t-JI for simple@ietf.org; Fri, 18 Jun 2004 10:17:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKAl-0006ce-00 for simple@ietf.org; Fri, 18 Jun 2004 10:16:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BbK9g-0005nI-00 for simple@ietf.org; Fri, 18 Jun 2004 10:15:44 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2004 10:20:56 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5IEFBhF014223; Fri, 18 Jun 2004 10:15:12 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJN34414; Fri, 18 Jun 2004 10:15:09 -0400 (EDT) Message-ID: <40D2F8ED.7060005@cisco.com> Date: Fri, 18 Jun 2004 10:15:09 -0400 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: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > hisham.khartabil@nokia.com wrote: > >> I really don't want the same resource to end up on the list more than >> once causing multiple subscriptions to the same resource. > > Generally, it doesnt make sense. But, there may be some reason why its > desired. Nothing breaks if you do it, I dont think, so the > canonicalization can be at SHOULD strength, not MUST. Well, its a great "feature" if the list is being used as a MESSAGE exploder. (Which may be a bit off topic here.) It gives me yet another way to cheaply generate spam and/or DoS attacks, by hammering the same recipient many times. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 10:49:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28417 for ; Fri, 18 Jun 2004 10:49:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKgj-0004BY-EI for simple-archive@ietf.org; Fri, 18 Jun 2004 10:49:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKfk-0003nX-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 10:48:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbKeq-000337-00; Fri, 18 Jun 2004 10:47:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKSr-0005AM-Cn; Fri, 18 Jun 2004 10:35:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKLT-0002RM-Fp for simple@megatron.ietf.org; Fri, 18 Jun 2004 10:27: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 KAA26778 for ; Fri, 18 Jun 2004 10:27:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKLS-0002xm-PK for simple@ietf.org; Fri, 18 Jun 2004 10:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKKT-0002Xy-00 for simple@ietf.org; Fri, 18 Jun 2004 10:26: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 1BbKJO-0001iK-00 for simple@ietf.org; Fri, 18 Jun 2004 10:25:46 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5IEP7Lp012691; Fri, 18 Jun 2004 09:25:07 -0500 Message-ID: <40D2FB42.4010001@dynamicsoft.com> Date: Fri, 18 Jun 2004 09:25:06 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] MSRP: delivery reports and transaction responses References: <2038BCC78B1AD641891A0D1AE133DBB701797C8F@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797C8F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, adam@dynamicsoft.com, cboulton@ubiquity.com, simple@ietf.org, mhammer@cisco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is somewhat incorrect. The "Send Response" column is entirely depending on the report-failure flag and is orthagonal to the report-success flag. hisham.khartabil@nokia.com wrote: > And here is the table to report success: > > report-success | Send Response? | Send report on success? > ----------------+----------------+------------------------ > true | MUST NOT | MUST > false | MUST NOT | MUST NOT > > /Hisham > > >>-----Original Message----- >>From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: 18.June.2004 01:13 >>To: Mike Hammer >>Cc: Ben Campbell; pkyzivat@cisco.com; Khartabil Hisham >>(Nokia-TP-MSW/Helsinki); cboulton@ubiquity.com; simple@ietf.org >>Subject: Re: [Simple] MSRP: delivery reports and transaction responses >> >> >>Mike Hammer wrote: >> >>>Would it not be possible to use just two binary flags and >> >>just make the >> >>>behavior of the receiving node a "Should not send DSN, MUST >> >>not send >> >>>response" with the sending node having a "MAY discard >> >>received DSN" or >> >>>is this a limited BW case for the sender? I would think >> >>that a relay >> >>>for BW-limited sender could also discard before a BW-limited link. >> >>The problem is that people envision doing things like sending >>administrative messages (e.g. "The IM system will be down from >>5:00 to 7:00 pm for maintenance") to thousands or even hundreds >>of thousands of users, and they don't want negative responses >>for the ones that fail. >> >> >>>report-success=true send response?, send Pos-DSN report >>>report-success=false send response?, no Pos-DSN report >>>report-failures=true send response, send Neg-DSN report >>>report-failures=false no response, no report >>>report-failures=partial no response, may send report >>>applies to all devices. >>> >>>I'm still missing some details (? above). >> >>The "Report Success" flag never, ever, ever has an impact >>on whether transaction responses are sent. In fact, relays >>never need to even consider the value of the "Report Success" >>flag. It is processed by endpoints only. >> >>report-failures | Send Response? | Send report on failure? >>----------------+----------------+------------------------ >>true | MUST | MUST >>false | MUST NOT | MUST NOT >>partial | MUST NOT | MAY >> >>/a >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 18 11:01:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29099 for ; Fri, 18 Jun 2004 11:01:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKsK-0000q3-Rl for simple-archive@ietf.org; Fri, 18 Jun 2004 11:01:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKrK-0000RP-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 11:00:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbKqM-0007SE-00; Fri, 18 Jun 2004 10:59:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKfq-0000xV-Qa; Fri, 18 Jun 2004 10:48:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKTE-0005KX-W4 for simple@megatron.ietf.org; Fri, 18 Jun 2004 10:35: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 KAA27759 for ; Fri, 18 Jun 2004 10:35:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKTE-0006Tl-7y for simple@ietf.org; Fri, 18 Jun 2004 10:35:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKSK-00063X-00 for simple@ietf.org; Fri, 18 Jun 2004 10:35:00 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BbKRM-0005Cz-00 for simple@ietf.org; Fri, 18 Jun 2004 10:34:00 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5IEPMLb011286; Fri, 18 Jun 2004 07:25:27 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJN35292; Fri, 18 Jun 2004 10:25:20 -0400 (EDT) Message-ID: <40D2FB50.7000706@cisco.com> Date: Fri, 18 Jun 2004 10:25:20 -0400 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: helei Subject: Re: [SIMPLE] Authorization of resource list back-end subscriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple mailinglist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit helei wrote: > The draft-ietf-simple-event-list-04 (expired, yes, but I hope it will be > revitalized soon) states that a resource list may have several subscribers. > It also states that the _RLS_ act as subscriber for the back-end > subscriptions to any non-local resources on the list. > > This makes me wonder: > - How can the non-local resources authorize the actual list subscribers > (those subscribing to the resource list)? The Watcher-info document would > only hold the RLS as a subscriber? Ideally the RLS is prepared to act as the watcher's agent, including having credentials permitting it to authenticate as such. > - Why prohibit reuse of information from one back-end subscription when the > actual subscription is not associated with the list subscriber? If the RLS has credentials to authenticate as agent for X when acting on X's behalf, and as agent for Y when acting on Y's behalf, then data received via subscription on behalf of X should not be released to subscriber Y, because subscription on behalf of Y could have divulged different info. OTOH, if the RLS always subscribes with a single set of credentials (its own), then there is probably no reason why it can't give that out to all its subscribers. (But in that case the RLS probably isn't going to receive the best information, because people won't trust who it is going to.) Paul > Shouldn't it be the _resource-list_ that acts as subscriber? > > Best regards, > Henrik Leion > > > _______________________________________________ > 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-bounces@ietf.org Fri Jun 18 11:18:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29825 for ; Fri, 18 Jun 2004 11:18:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbL8s-0007NF-IX for simple-archive@ietf.org; Fri, 18 Jun 2004 11:18:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbL89-00070J-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 11:18:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbL7G-0006QG-00; Fri, 18 Jun 2004 11:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbL3b-0006qt-LR; Fri, 18 Jun 2004 11:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKwS-0005FW-9H for simple@megatron.ietf.org; Fri, 18 Jun 2004 11:06: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 LAA29297 for ; Fri, 18 Jun 2004 11:06:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbKwR-0002Q0-EV for simple@ietf.org; Fri, 18 Jun 2004 11:06:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbKvc-00022D-00 for simple@ietf.org; Fri, 18 Jun 2004 11:05:17 -0400 Received: from epact.se ([192.36.138.128]) by ietf-mx with esmtp (Exim 4.12) id 1BbKuf-0001Qs-00 for simple@ietf.org; Fri, 18 Jun 2004 11:04:17 -0400 Received: from krypton (krypton.epact.se [192.36.138.36]) by epact.se (8.12.11/8.12.10) with SMTP id i5IF3koU009151 for ; Fri, 18 Jun 2004 17:03:47 +0200 From: "Henrik Leion" To: "Simple mailinglist" Subject: RE: [SIMPLE] Authorization of resource list back-end subscriptions Date: Fri, 18 Jun 2004 17:07:13 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40D2FB50.7000706@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit [Inline comments after this suggestion] I think the discussions on authorization rules, filters and watcher info would allow a better and more powerful solution: - Why can't the resource-list acts as the subscriber to the non-local resource, instead of the RLS. The watcher event template package would allow the presentity to "roll-back" the two subscriptions to see who ultimately will receive notifications from the list (by subscribing to resource-list-uri.winfo, should this list contain any list, the presentity could subscribe to them to). - The back-end resource should be allowed (if he can authenticate himself to the RLS which is in another domain) to set authorization rules applicable to him in the resource-list's authorization rule-set, in order to block his information from reaching specific subscribers to the list. Consequences: - The real users in the list will have the same control over their presence information as in direct subscriptions, including filtering and authorisation. - No need to upload credentials to server just to have lists with people from other domains in them. - The RLS could reuse existing back-end subscriptions by checking resource-list policy and updating resource-list watcher-info - OTOH, if the presentity has not created a complete authorization policy and is not subscribing to the winfo of the list, new subscriptions might starve. / Henrik Leion > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: den 18 juni 2004 16:25 > To: helei > Cc: Simple mailinglist > Subject: Re: [SIMPLE] Authorization of resource list back-end > subscriptions > > > > > helei wrote: > > The draft-ietf-simple-event-list-04 (expired, yes, but I hope it will be > > revitalized soon) states that a resource list may have several > subscribers. > > It also states that the _RLS_ act as subscriber for the back-end > > subscriptions to any non-local resources on the list. > > > > This makes me wonder: > > - How can the non-local resources authorize the actual list subscribers > > (those subscribing to the resource list)? The Watcher-info > document would > > only hold the RLS as a subscriber? > > Ideally the RLS is prepared to act as the watcher's agent, including > having credentials permitting it to authenticate as such. But what if we subscribe to a list, which contains an external list which contains a user. The second RLS would then only have the credentials for authorizing the first RLS at best, not the subscriber. Right? > > > - Why prohibit reuse of information from one back-end > subscription when the > > actual subscription is not associated with the list subscriber? > > If the RLS has credentials to authenticate as agent for X when acting on > X's behalf, and as agent for Y when acting on Y's behalf, then data > received via subscription on behalf of X should not be released to > subscriber Y, because subscription on behalf of Y could have divulged > different info. > > OTOH, if the RLS always subscribes with a single set of credentials (its > own), then there is probably no reason why it can't give that out to all > its subscribers. (But in that case the RLS probably isn't going to > receive the best information, because people won't trust who it is going > to.) > Isn't that a more likely scenario than people uploading credentials to servers? > Paul > > > Shouldn't it be the _resource-list_ that acts as subscriber? > > > > Best regards, > > Henrik Leion > > > > > > _______________________________________________ > > 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-bounces@ietf.org Fri Jun 18 12:40:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04255 for ; Fri, 18 Jun 2004 12:40:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbMPU-0006bY-85 for simple-archive@ietf.org; Fri, 18 Jun 2004 12:40:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbMOL-000677-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 12:39:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BbMN8-00054n-01; Fri, 18 Jun 2004 12:37:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BbMJM-0006Xm-AO; Fri, 18 Jun 2004 12:33:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbM7i-0007xX-UV; Fri, 18 Jun 2004 12:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbLoi-0001y1-Je for simple@megatron.ietf.org; Fri, 18 Jun 2004 12:02: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 MAA02555 for ; Fri, 18 Jun 2004 12:02:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbLoh-0000E6-P9 for simple@ietf.org; Fri, 18 Jun 2004 12:02:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbLnh-0007WG-00 for simple@ietf.org; Fri, 18 Jun 2004 12:01:10 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BbLlP-0006LK-00 for simple@ietf.org; Fri, 18 Jun 2004 11:58:47 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 18 Jun 2004 08:58:18 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 18 Jun 2004 08:58:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: delivery reports and transaction responses Date: Fri, 18 Jun 2004 08:58:18 -0700 Message-ID: Thread-Topic: [Simple] MSRP: delivery reports and transaction responses thread-index: AcRVP8/zwr9UqGMHQb2Lkf+61rdu/AACcaNQ From: "Orit Levin" To: "Mike Hammer" , "Adam Roach" X-OriginalArrivalTime: 18 Jun 2004 15:58:17.0220 (UTC) FILETIME=[11C54440:01C4554D] Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, hisham.khartabil@nokia.com, cboulton@ubiquity.com, Ben Campbell , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Positive transaction responses are generated "if and only if" the negative-report flag is set to TRUE. Positive transaction response is a "tool" for generating Negative Reports only. It is the means for letting know the previous hop whether the SEND has been definitely successfully delivered to the next hop. Otherwise, if the positive response doesn't arrive (and the negative response doesn't arrive either) after a certain period of time (e.g. after the local transaction timer expires) the MSRP entity MUST generate the negative DSN report. The local transaction timer is maintained for a SEND with negative-report flag set to "Yes" only. Orit. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Mike Hammer Sent: Friday, June 18, 2004 6:44 AM To: Adam Roach Cc: pkyzivat@cisco.com; hisham.khartabil@nokia.com; cboulton@ubiquity.com; Ben Campbell; simple@ietf.org Subject: Re: [Simple] MSRP: delivery reports and transaction responses At 06:51 PM 6/17/2004 -0500, Adam Roach wrote: >Mike Hammer wrote: > >>At 05:12 PM 6/17/2004 -0500, Adam Roach wrote: >> >>>...people envision doing things like sending >>>administrative messages (e.g. "The IM system will be down from >>>5:00 to 7:00 pm for maintenance") to thousands or even hundreds >>>of thousands of users, and they don't want negative responses >>>for the ones that fail. >> >> >>Sounds like you would want to suppress successful responses too, but that=20 >>is not an option for what is proposed. > >Ummm... yes it is. Setting "report-failure" to "false" guarantees that you=20 >don't get any negative reports, and that you don't get any transaction=20 >responses (positive or negative). > >/a Now, you've totally confused me. My understanding was that the=20 report-failure flag governed the behavior of the negative reports and=20 negative responses, while the report-success flag governed the positive=20 reports, but only for the endpoints and not for the positive responses;=20 where the sending of the positive transaction response was not governed by=20 either flag. This is why I have decided to withdraw until I see the official=20 description. The answers from this email thread have gotten me closer to=20 understanding, but have not been completely consistent. Mike _______________________________________________ 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-bounces@ietf.org Fri Jun 18 17:35:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23839 for ; Fri, 18 Jun 2004 17:35:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbR13-0003fR-FR for simple-archive@ietf.org; Fri, 18 Jun 2004 17:35:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbQyw-0002n1-00 for simple-archive@ietf.org; Fri, 18 Jun 2004 17:33:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbQxH-0001vm-09; Fri, 18 Jun 2004 17:31:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbQbC-0003QS-Av; Fri, 18 Jun 2004 17:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbQIW-0007bB-Nm for simple@megatron.ietf.org; Fri, 18 Jun 2004 16:49: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 QAA21478 for ; Fri, 18 Jun 2004 16:49:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbQIV-0002eB-IS for simple@ietf.org; Fri, 18 Jun 2004 16:49:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbQGY-0001tJ-00 for simple@ietf.org; Fri, 18 Jun 2004 16:47:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BbQE3-0000ge-00 for simple@ietf.org; Fri, 18 Jun 2004 16:44:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2004 16:49:47 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5IKi0wc017947; Fri, 18 Jun 2004 16:44:00 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJN69233; Fri, 18 Jun 2004 16:43:59 -0400 (EDT) Message-ID: <40D3540F.2010103@cisco.com> Date: Fri, 18 Jun 2004 16:43:59 -0400 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: Henrik Leion Subject: Re: [SIMPLE] Authorization of resource list back-end subscriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple mailinglist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henrik Leion wrote: > [Inline comments after this suggestion] > > I think the discussions on authorization rules, filters and watcher info > would allow a better and more powerful solution: > > - Why can't the resource-list acts as the subscriber to the non-local > resource, instead of the RLS. Well, that is an interesting thought. Possibly it could be made to work. A number of issues/implications (maybe not fatal) come to mind: - what kind of credential could the RLS have and provide when subscribing that authenticates it as the resource-list? - in case of private lists (e.g. I am the only one who subscribes to *my* buddy list) having credentials for my buddy list is no easier than having credentials for me. - if the RLS server has lists L1 and L2 that both have a reference to presentity P, then it still can't use a single subscription to P and provide results to subscribers of both L1 and L2. > The watcher event template package would allow > the presentity to "roll-back" the two subscriptions to see who ultimately > will receive notifications from the list (by subscribing to > resource-list-uri.winfo, should this list contain any list, the presentity > could subscribe to them to). Well, maybe it *could* but that sounds really cumbersome, expensive, and not especially reliable. Can I ever safely decide what to disclose based on who I think is currently subscribing to that list, rather than who potentially *could* subscribe to it? > - The back-end resource should be allowed (if he can authenticate himself > to the RLS which is in another domain) to set authorization rules applicable > to him in the resource-list's authorization rule-set, in order to block his > information from reaching specific subscribers to the list. Huh? I don't follow. > Consequences: > - The real users in the list will have the same control over their presence > information as in direct subscriptions, including filtering and > authorisation. > - No need to upload credentials to server just to have lists with people > from other domains in them. > - The RLS could reuse existing back-end subscriptions by checking > resource-list policy and updating resource-list watcher-info > - OTOH, if the presentity has not created a complete authorization policy > and is not subscribing to the winfo of the list, new subscriptions might > starve. Not sure I buy this, but I also don't fully understand. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 19 07:16:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15239 for ; Sat, 19 Jun 2004 07:16:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bbdq2-0001DF-Jg for simple-archive@ietf.org; Sat, 19 Jun 2004 07:16:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bbdp5-0000ah-00 for simple-archive@ietf.org; Sat, 19 Jun 2004 07:15:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bbdo3-0000HT-00; Sat, 19 Jun 2004 07:14:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbdiQ-0008Ev-Uf; Sat, 19 Jun 2004 07:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbdgT-0007x2-TE for simple@megatron.ietf.org; Sat, 19 Jun 2004 07:06: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 HAA14994 for ; Sat, 19 Jun 2004 07:06:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbdgR-0005rc-Hj for simple@ietf.org; Sat, 19 Jun 2004 07:06:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbdfS-0005Wi-00 for simple@ietf.org; Sat, 19 Jun 2004 07:05:50 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bbdet-0005BL-00 for simple@ietf.org; Sat, 19 Jun 2004 07:05:15 -0400 Received: from dynamicsoft.com ([63.113.46.75]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5JB4pbo027171; Sat, 19 Jun 2004 07:04:51 -0400 (EDT) Message-ID: <40D41DBF.10209@dynamicsoft.com> Date: Sat, 19 Jun 2004 07:04:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> In-Reply-To: <40D2F8ED.7060005@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > Jonathan Rosenberg wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> I really don't want the same resource to end up on the list more than >>> once causing multiple subscriptions to the same resource. >> >> >> Generally, it doesnt make sense. But, there may be some reason why its >> desired. Nothing breaks if you do it, I dont think, so the >> canonicalization can be at SHOULD strength, not MUST. > > > Well, its a great "feature" if the list is being used as a MESSAGE > exploder. (Which may be a bit off topic here.) > > It gives me yet another way to cheaply generate spam and/or DoS attacks, > by hammering the same recipient many times. Even if the same URI can appear only once, you might be able to hammer the same recipient many times by using many different URI at the same host. If you want to prevent this attack, you need a more systematic way of getting authorization for message receipt, as we discussed at the interim. As such, I don't think this particular MUST/SHOULD decision really hinges at all on the exploder question. 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-bounces@ietf.org Sun Jun 20 22:40:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16824 for ; Sun, 20 Jun 2004 22:40:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcEjT-0001p2-1C for simple-archive@ietf.org; Sun, 20 Jun 2004 22:40:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcEiS-0001dF-00 for simple-archive@ietf.org; Sun, 20 Jun 2004 22:39:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcEhq-0001Pd-00; Sun, 20 Jun 2004 22:38:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcEg3-0002M7-BM; Sun, 20 Jun 2004 22:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcEex-0002E3-K5 for simple@megatron.ietf.org; Sun, 20 Jun 2004 22:35: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 WAA16491 for ; Sun, 20 Jun 2004 22:35:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcEev-0000oC-Oy for simple@ietf.org; Sun, 20 Jun 2004 22:35:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcEe5-0000YA-00 for simple@ietf.org; Sun, 20 Jun 2004 22:34:53 -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 1BcEd2-0000DP-00 for simple@ietf.org; Sun, 20 Jun 2004 22:33:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2004 19:35:13 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5L2XFgI004124; Sun, 20 Jun 2004 19:33:16 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJO47932; Sun, 20 Jun 2004 22:33:14 -0400 (EDT) Message-ID: <40D648EA.6080700@cisco.com> Date: Sun, 20 Jun 2004 22:33:14 -0400 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: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Paul Kyzivat wrote: > >> Well, its a great "feature" if the list is being used as a MESSAGE >> exploder. (Which may be a bit off topic here.) >> >> It gives me yet another way to cheaply generate spam and/or DoS >> attacks, by hammering the same recipient many times. > > Even if the same URI can appear only once, you might be able to hammer > the same recipient many times by using many different URI at the same host. > > If you want to prevent this attack, you need a more systematic way of > getting authorization for message receipt, as we discussed at the > interim. As such, I don't think this particular MUST/SHOULD decision > really hinges at all on the exploder question. I guess you are right, that it would be possible to get around the uniqueness issue by spinning variants on the same address, perhaps by adding a url parameter. I wasn't intending to be entirely serious here. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 21 02:51:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15156 for ; Mon, 21 Jun 2004 02:51:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcIeN-0001m9-Js for simple-archive@ietf.org; Mon, 21 Jun 2004 02:51:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcIdP-0001Wp-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 02:50:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcIcR-00017k-00; Mon, 21 Jun 2004 02:49:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcIZa-0003KX-Ic; Mon, 21 Jun 2004 02:46:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcITJ-0001nK-O2 for simple@megatron.ietf.org; Mon, 21 Jun 2004 02:40: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 CAA14183 for ; Mon, 21 Jun 2004 02:40:00 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcITH-0006YK-HF for simple@ietf.org; Mon, 21 Jun 2004 02:39:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcISM-0006Hg-00 for simple@ietf.org; Mon, 21 Jun 2004 02:39:03 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BcIRZ-00060z-00 for simple@ietf.org; Mon, 21 Jun 2004 02:38:14 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5L6c6624351; Mon, 21 Jun 2004 09:38:06 +0300 (EET DST) X-Scanned: Mon, 21 Jun 2004 09:37:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5L6btU1007792; Mon, 21 Jun 2004 09:37:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gRTYT3; Mon, 21 Jun 2004 09:37:53 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5L6bqH06181; Mon, 21 Jun 2004 09:37:52 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Jun 2004 09:37:39 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Jun 2004 09:37:38 +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] XCAP Issue 2 Interim Summary: Positional Insertions Date: Mon, 21 Jun 2004 09:37:38 +0300 Message-ID: Thread-Topic: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions Thread-Index: AcRUZ7U5aDTXw/9SRs2TyshsjJDJTwAkvudg To: , X-OriginalArrivalTime: 21 Jun 2004 06:37:38.0671 (UTC) FILETIME=[3EDF47F0:01C4575A] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I would prefer including positional inserts in XCAP.=20 As far as I have understood, the additional implementation complexity is = quite small, and they provide some efficiency benefit in certain = situations. I don't think this is an issue for initial usages of XCAP, = but once XCAP has been implemented e.g. for cellular devices, people may = want to use it for other purposes too. I don't think it is realistic to = assume something like XUpdate being available in this way.=20 Markus=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 17 June, 2004 15:07 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional > Insertions >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Jonathan, > >=20 > > Thanks for the analysis. > >=20 > > Reading your analysis actually brings me to the opposite conclusion > > to the one you made. That is, we need positional insertions. There > > are so many rules, restriction, and guide lines that need to be > > educated to current and future designers of XCAP friendly schemas. > > Wouldn't it be a much better investment if we allow positional > > insertions now and avoid schema misdesign? >=20 > I don't think any of the guidelines represent a schema mis-design. >=20 > >=20 > > You haven't explicitly listed the issues with positional insertions, > > but instead you listed the problems that it solves. Can you please > > educate the rest of us what the real problems are with positional > > insertions? >=20 > It was just complexity. Positional insertions would require us to=20 > support multiple predicates (i.e., more than one [] rule). We could=20 > restrict it to just two in our case, and indeed, restrict the first=20 > predicate to be a positional selector only. I think that=20 > might help the=20 > complexity a bit. However, there is definitely more logic and code=20 > required to support it than not. How much exactly? Depends on the=20 > implementation. I'll send a separate note in the next day or=20 > so with a=20 > pseudo-code view of what a minimal implementation would be,=20 > so folks can=20 > get a sense of it. >=20 > The meta-issue was that the whole idea with xcap is that what we are=20 > generally doing is reading and writing a document from a=20 > server (like a=20 > buddy list), but sometimes, you need to read or write a piece=20 > of it as=20 > an optimization, so we have the notion of sub-document=20 > addressing. When=20 > you view the design goal as reading and writing of entire=20 > documents with=20 > sub-document operations as a performance optimization, things like=20 > positional inserts teeter on the boundary between this view, and the=20 > view of xcap as an XML database protocol. I think that, if we are=20 > defining an XML database protocol, we would probably start from a=20 > different approach, along the lines of XUpdate. >=20 > I must say that, on the issue of positional inserts, I am on=20 > the fence.=20 > I do see the "keep it barebones simple" argument, especially as it=20 > relates to the view of xcap as an optimization around reading and=20 > writing of documents. On the other hand, from a code perspective, I=20 > don't think positional inserts is actually that complicated, and it=20 > does, as Hisham pointed out, remove a lot of "schema design=20 > guidelines"=20 > that I would otherwise need to introduce to deal with it. >=20 > Comments from others? Even a "do positional inserts" or "dont do it"=20 > response is helpful. >=20 > Thanks, > Jonathan R. >=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 > _______________________________________________ > 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-bounces@ietf.org Mon Jun 21 04:40:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21856 for ; Mon, 21 Jun 2004 04:40:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcKM6-0003yX-Ag for simple-archive@ietf.org; Mon, 21 Jun 2004 04:40:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcKLB-0003kE-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 04:39:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcKKN-0003Hc-00; Mon, 21 Jun 2004 04:38:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcKF2-0003Q6-M7; Mon, 21 Jun 2004 04:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcKCI-0002sK-I0 for simple@megatron.ietf.org; Mon, 21 Jun 2004 04:30: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 EAA21297 for ; Mon, 21 Jun 2004 04:30:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcKCG-0001Xn-BS for simple@ietf.org; Mon, 21 Jun 2004 04:30:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcKBH-0001JB-00 for simple@ietf.org; Mon, 21 Jun 2004 04:29:32 -0400 Received: from epact.se ([192.36.138.128]) by ietf-mx with esmtp (Exim 4.12) id 1BcKAE-0000sV-00 for simple@ietf.org; Mon, 21 Jun 2004 04:28:26 -0400 Received: from krypton (krypton.epact.se [192.36.138.36]) by epact.se (8.12.11/8.12.10) with SMTP id i5L8RukH029657 for ; Mon, 21 Jun 2004 10:27:57 +0200 From: "Henrik Leion" To: "Simple mailinglist" Subject: RE: [SIMPLE] Authorization of resource list back-end subscriptions Date: Mon, 21 Jun 2004 10:30:30 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40D3540F.2010103@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Well, I just thought I'd toss in the idea. I believe that domains will be small (office or home networks even) and that both inter-domain subscriptions and resource-list subscriptions will be very common. I was thinking in these lines: - If the ideas with filters, authorization rules and partial presence will be implemented, how many users can there be on one presence-server? Parsing xml-docs is quite more time-consuming than just forwarding requests. - How large parts of the resource-lists will actually come from the same presence-server and how much is back-end subscriptions? - If subscriptions are to be authorized using watcher-info notification and XCAP, isn't it a bit boring that it just says "pres.example.com" instead of at least saying what resource-list your presence is publicated on? Better yet is that the winfo-file states the subscribers to the resource-lists. More inline. > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf > Of Paul Kyzivat > Sent: den 18 juni 2004 22:44 > To: Henrik Leion > Cc: Simple mailinglist > Subject: Re: [SIMPLE] Authorization of resource list back-end > subscriptions > > > > > Henrik Leion wrote: > > [Inline comments after this suggestion] > > > > I think the discussions on authorization rules, filters and watcher info > > would allow a better and more powerful solution: > > > > - Why can't the resource-list acts as the subscriber to the non-local > > resource, instead of the RLS. > > Well, that is an interesting thought. Possibly it could be made to work. > A number of issues/implications (maybe not fatal) come to mind: > > - what kind of credential could the RLS have and provide when > subscribing that authenticates it as the resource-list? > Well, actually I don't know. But what difference is there between an RLS authenticating itself to a presentity using some "sip:pres.example.com" URI, than should it use "sip:adam-friends@lists.example.com"? In either case the presentity have probably never heard of example.com before. > - in case of private lists (e.g. I am the only one who subscribes to > *my* buddy list) having credentials for my buddy list is no easier than > having credentials for me. Yes, I was thinking in the lines of public lists; intranet address-lists, conferences, discussion groups etc. But I'm under the impression that the RLS does not use the presentities credentials when creating a back-end subscription but instead acts on its own, "RLSes acts as a subscriber" [event-list draft]. > > - if the RLS server has lists L1 and L2 that both have a reference to > presentity P, then it still can't use a single subscription to P and > provide results to subscribers of both L1 and L2. Yes it could. P.winfo would contain L1 and L2 along with all other watchers that are interested in the presence of P. If P wants to check who actually subscribes to L1 and L2, he would consult L1.winfo and L2.winfo. Another idea is to add a namespace to winfo for resourcelists, now P can see anybody subscribing to him directly, instead of just knowing that an RLS is subscribing. Example, If S1 and S2 subscribes to L1, L2 and S3 also subscribes to P, P would receive this winfo: S1@another.domain.com S2@athird.domain.com S3@example.com In comparison, if the RLS acts as subscriber the watcher info would look like: rls-server@another.domain.com rls-server@athird.domain.com S3@example.com Where the user will have no idea what his presence information will be used for. In the former example there is of course no guarantee that the RLS:s in "another.domain.com" and "athird.domain.com" are telling the truth about the subscribers, but P will at least have more information when making his decision. > > > The watcher event template package would allow > > the presentity to "roll-back" the two subscriptions to see who > ultimately > > will receive notifications from the list (by subscribing to > > resource-list-uri.winfo, should this list contain any list, the > presentity > > could subscribe to them to). > > Well, maybe it *could* but that sounds really cumbersome, expensive, and > not especially reliable. Can I ever safely decide what to disclose based > on who I think is currently subscribing to that list, rather than who > potentially *could* subscribe to it? But that's the whole idea behind presence authorization using winfo-lists, isn't it? That you can trust the presence server that it only sends your presence information to those watchers that are marked "active" in your winfo-file. When new subscriptions come, the presence server will either allow or disallow it judging from authorization rules, or otherwise set the subscription-state to "pending" and let the presentity decide. If you don't trust that the server will act this way in the future, send less information. > > > - The back-end resource should be allowed (if he can > authenticate himself > > to the RLS which is in another domain) to set authorization > rules applicable > > to him in the resource-list's authorization rule-set, in order > to block his > > information from reaching specific subscribers to the list. > > Huh? I don't follow. Those present on a resource-list should be allowed to create resource-list authorization rules appliable to their own presence. L1 has two subscribers S1a and S1b. P may be authorized to create a rule in L1.auth that always transforms his presence to appear offline to S1b, whilst S1a will get P's true presence. The authorization rules of a resource list should belong to the people on it, at least in public applications, such as conference lists. But in a black-list or buddylist application the idea is probably quite stupid. > > > Consequences: > > - The real users in the list will have the same control over > their presence > > information as in direct subscriptions, including filtering and > > authorisation. > > - No need to upload credentials to server just to have lists > with people > > from other domains in them. > > - The RLS could reuse existing back-end subscriptions by checking > > resource-list policy and updating resource-list watcher-info > > - OTOH, if the presentity has not created a complete > authorization policy > > and is not subscribing to the winfo of the list, new subscriptions might > > starve. > > Not sure I buy this, but I also don't fully understand. > /Henrik > 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-bounces@ietf.org Mon Jun 21 06:01:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26699 for ; Mon, 21 Jun 2004 06:01:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcLbq-0007ef-OI for simple-archive@ietf.org; Mon, 21 Jun 2004 06:01:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcLal-0007Q6-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 05:59:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcLZx-00077W-00; Mon, 21 Jun 2004 05:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcLTe-0006Au-Ox; Mon, 21 Jun 2004 05:52:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcLNx-0005fd-08 for simple@megatron.ietf.org; Mon, 21 Jun 2004 05:46: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 FAA25832 for ; Mon, 21 Jun 2004 05:46:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcLNu-0004Iq-NT for simple@ietf.org; Mon, 21 Jun 2004 05:46:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcLMx-00045D-00 for simple@ietf.org; Mon, 21 Jun 2004 05:45:40 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BcLMB-0003ed-00 for simple@ietf.org; Mon, 21 Jun 2004 05:44:51 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5L9iAF27775 for ; Mon, 21 Jun 2004 04:44:11 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Jun 2004 10:44:09 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C614259@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg , hisham.khartabil@nokia.com Subject: RE: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions Date: Mon, 21 Jun 2004 10:44:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 My view at the moment is "keep it simple" and not do positional insertions in XCAP. If there is a need for an enhanced capability, then there would appear to be other ways of modifying XML documents that could be brought into play outside the use of XCAP, and I suspect that at the most, IETF SIMPLE should just allow these other mechanisms to be used. That keeps XCAP at a low level where the majority of user applications will work perfectly well, and leaves the high level stuff to the 1% that can use something else to do the more sophisticated things. Additionally, to do some of these high level things, I am not sure I would start from XCAP in the first place. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 17 June 2004 13:07 > To: hisham.khartabil@nokia.com > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional > Insertions > > > > > hisham.khartabil@nokia.com wrote: > > > Jonathan, > > > > Thanks for the analysis. > > > > Reading your analysis actually brings me to the opposite conclusion > > to the one you made. That is, we need positional insertions. There > > are so many rules, restriction, and guide lines that need to be > > educated to current and future designers of XCAP friendly schemas. > > Wouldn't it be a much better investment if we allow positional > > insertions now and avoid schema misdesign? > > I don't think any of the guidelines represent a schema mis-design. > > > > > You haven't explicitly listed the issues with positional insertions, > > but instead you listed the problems that it solves. Can you please > > educate the rest of us what the real problems are with positional > > insertions? > > It was just complexity. Positional insertions would require us to > support multiple predicates (i.e., more than one [] rule). We could > restrict it to just two in our case, and indeed, restrict the first > predicate to be a positional selector only. I think that > might help the > complexity a bit. However, there is definitely more logic and code > required to support it than not. How much exactly? Depends on the > implementation. I'll send a separate note in the next day or > so with a > pseudo-code view of what a minimal implementation would be, > so folks can > get a sense of it. > > The meta-issue was that the whole idea with xcap is that what we are > generally doing is reading and writing a document from a > server (like a > buddy list), but sometimes, you need to read or write a piece > of it as > an optimization, so we have the notion of sub-document > addressing. When > you view the design goal as reading and writing of entire > documents with > sub-document operations as a performance optimization, things like > positional inserts teeter on the boundary between this view, and the > view of xcap as an XML database protocol. I think that, if we are > defining an XML database protocol, we would probably start from a > different approach, along the lines of XUpdate. > > I must say that, on the issue of positional inserts, I am on > the fence. > I do see the "keep it barebones simple" argument, especially as it > relates to the view of xcap as an optimization around reading and > writing of documents. On the other hand, from a code perspective, I > don't think positional inserts is actually that complicated, and it > does, as Hisham pointed out, remove a lot of "schema design > guidelines" > that I would otherwise need to introduce to deal with it. > > Comments from others? Even a "do positional inserts" or "dont do it" > response is helpful. > > 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-bounces@ietf.org Mon Jun 21 06:06:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27062 for ; Mon, 21 Jun 2004 06:06:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcLgj-00016G-BW for simple-archive@ietf.org; Mon, 21 Jun 2004 06:06:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcLfl-0000qW-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 06:05:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcLf1-0000Yw-00; Mon, 21 Jun 2004 06:04:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcLcy-0007WV-J7; Mon, 21 Jun 2004 06:02:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcLVg-0006UQ-2A for simple@megatron.ietf.org; Mon, 21 Jun 2004 05:54: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 FAA26248 for ; Mon, 21 Jun 2004 05:54:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcLVd-0006Db-Oz for simple@ietf.org; Mon, 21 Jun 2004 05:54:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcLUa-0005mS-00 for simple@ietf.org; Mon, 21 Jun 2004 05:53:33 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BcLTA-0005S1-00 for simple@ietf.org; Mon, 21 Jun 2004 05:52:04 -0400 Received: from dynamicsoft.com ([63.113.46.75]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5L9plbo027932; Mon, 21 Jun 2004 05:51:47 -0400 (EDT) Message-ID: <40D6AF9F.5000609@dynamicsoft.com> Date: Mon, 21 Jun 2004 05:51:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Leion Subject: Re: [SIMPLE] Authorization of resource list back-end subscriptions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple mailinglist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henrik Leion wrote: > Well, I just thought I'd toss in the idea. I believe that domains will be > small (office or home networks even) and that both inter-domain > subscriptions and resource-list subscriptions will be very common. I was > thinking in these lines: > > - If the ideas with filters, authorization rules and partial presence will > be implemented, how many users can there be on one presence-server? Parsing > xml-docs is quite more time-consuming than just forwarding requests. Its not clear to me how what you are proposing improves performance in any way. I guess, to invert that, what is the primary problem you are concerned about? > - How large parts of the resource-lists will actually come from the same > presence-server and how much is back-end subscriptions? > - If subscriptions are to be authorized using watcher-info notification and > XCAP, isn't it a bit boring that it just says "pres.example.com" instead of > at least saying what resource-list your presence is publicated on? Better > yet is that the winfo-file states the subscribers to the resource-lists. When having to choose between pres.example.com and sip:friends@example.com, you are probably right that the resource list is a better identifier. However, the intention of resource lists is that the back end subsriptions are authenticated as if they came from the user subscribing to the resource list. That is, if bob subscribes to his resource list, then the back-end subscriptions would include credentials for bob. Section 7.1 talks about using asserted identities for this purpose. I think that such an approach is really the best model. WHen it works that way, the policies that the presentity establishes don't need to depend on whether Bob is coming in directly or through a list. The presentity doesnt need to know anything about lists, in fact. They merely serve as an optimization for performance, rather than as an actor in authentication systems. -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-bounces@ietf.org Mon Jun 21 06:10:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27336 for ; Mon, 21 Jun 2004 06:10:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcLl7-0002Ej-V9 for simple-archive@ietf.org; Mon, 21 Jun 2004 06:10:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcLk8-00020l-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 06:09:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcLjI-0001ar-00; Mon, 21 Jun 2004 06:08:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcLds-0007cg-6n; Mon, 21 Jun 2004 06:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcLbp-0007MS-2b for simple@megatron.ietf.org; Mon, 21 Jun 2004 06:01: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 GAA26690 for ; Mon, 21 Jun 2004 06:00:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcLbm-0007e8-Nx for simple@ietf.org; Mon, 21 Jun 2004 06:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcLae-0007PB-00 for simple@ietf.org; Mon, 21 Jun 2004 05:59:49 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BcLZl-0006ve-00 for simple@ietf.org; Mon, 21 Jun 2004 05:58:53 -0400 Received: from dynamicsoft.com ([63.113.46.75]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5L9wRbo027935; Mon, 21 Jun 2004 05:58:28 -0400 (EDT) Message-ID: <40D6B130.5060303@dynamicsoft.com> Date: Mon, 21 Jun 2004 05:58:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D19@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D19@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. mikko.lonnfors@nokia.com wrote: >>On Fri, 2004-06-11 at 11:44, ext Jonathan Rosenberg wrote: >>...snip... >> >>>I think we are going to need to make sure that the >> >>authorization stuff >> >>>is aligned with the PIDF/RPID data models no matter what we >> >>do. Part of >> >>>my difficulties in wrapping up the authorization spec is >> >>that we keep >> >>>tripping on the "what is a tuple" issue in figuring out >> >>what kind of >> >>>functions to include in the authorization policies. >> >>This is true. So from this point of view, it would be good >>not to let PIDF restrict us in making things explicit. >> >> >>>You raise a good point on partial notifications. Using a separate >>> element also won't play well with that. I'd hate to force >>>things into tuples when they don't belong, just because partial >>>notifications doesnt know about anything but tuples. >> >>I agree. >> >>Mikko, what do you think about this? > > >>From partial notification point of view it should be enough if these new > elements would have similar ID attribute as tuples currently have and > that they would share the same ID space. If there can be multiple > occurrences of these new 'wrapper types' having similar ID as in tuple > makes would be beneficial whether you use partial notifications or not. I think it makes sense to use the same id attribute and space. My question is, if you did this, would a client that implemented the partial notification spec, but didnt know about a new element, peer to , properly construct a PIDF document when sent partial notifications that indicate changes or removal of elements? -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-bounces@ietf.org Mon Jun 21 14:22:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13666 for ; Mon, 21 Jun 2004 14:22:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcTRS-0001Hz-5u for simple-archive@ietf.org; Mon, 21 Jun 2004 14:22:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcTQT-00010o-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 14:21:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcTPZ-0000Uu-00; Mon, 21 Jun 2004 14:20:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcTKS-0003bG-5n; Mon, 21 Jun 2004 14:15:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcRU5-00089A-DL for simple@megatron.ietf.org; Mon, 21 Jun 2004 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 MAA29558 for ; Mon, 21 Jun 2004 12:17:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcRU4-00062b-Gq for simple@ietf.org; Mon, 21 Jun 2004 12:17:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcQzX-0007a7-00 for simple@ietf.org; Mon, 21 Jun 2004 11:45:52 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BcPpa-00076f-00 for simple@ietf.org; Mon, 21 Jun 2004 10:31:30 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5LEUgLp027013; Mon, 21 Jun 2004 09:30:43 -0500 Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices From: Robert Sparks To: Paul Kyzivat In-Reply-To: <40D648EA.6080700@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> Content-Type: text/plain Message-Id: <1087828039.2162.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 21 Jun 2004 09:27:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Hisham Khartabil , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We're not expecting these URIs to have parameters normally, but is there anything that prevents them from being provided? RjS On Sun, 2004-06-20 at 21:33, Paul Kyzivat wrote: > Jonathan Rosenberg wrote: > > Paul Kyzivat wrote: > > > >> Well, its a great "feature" if the list is being used as a MESSAGE > >> exploder. (Which may be a bit off topic here.) > >> > >> It gives me yet another way to cheaply generate spam and/or DoS > >> attacks, by hammering the same recipient many times. > > > > Even if the same URI can appear only once, you might be able to hammer > > the same recipient many times by using many different URI at the same host. > > > > If you want to prevent this attack, you need a more systematic way of > > getting authorization for message receipt, as we discussed at the > > interim. As such, I don't think this particular MUST/SHOULD decision > > really hinges at all on the exploder question. > > I guess you are right, that it would be possible to get around the > uniqueness issue by spinning variants on the same address, perhaps by > adding a url parameter. > > I wasn't intending to be entirely serious here. > > 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-bounces@ietf.org Mon Jun 21 14:28:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14097 for ; Mon, 21 Jun 2004 14:28:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcTWg-0002uB-8p for simple-archive@ietf.org; Mon, 21 Jun 2004 14:28:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcTVW-0002WU-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 14:27:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcTUL-0001us-00; Mon, 21 Jun 2004 14:25:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcTKV-0003bZ-3b; Mon, 21 Jun 2004 14:15:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcRVJ-0000iv-EQ for simple@megatron.ietf.org; Mon, 21 Jun 2004 12:18: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 MAA29724 for ; Mon, 21 Jun 2004 12:18:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcRVI-0006DH-EG for simple@ietf.org; Mon, 21 Jun 2004 12:18:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcR0r-00002q-00 for simple@ietf.org; Mon, 21 Jun 2004 11:47:15 -0400 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BcPtR-0007VR-00 for simple@ietf.org; Mon, 21 Jun 2004 10:35:30 -0400 Received: from syd-core-1.cisco.com (64.104.193.198) by ind-iport-1.cisco.com with ESMTP; 22 Jun 2004 01:43:25 +0530 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5LHXmG4021892; Tue, 22 Jun 2004 01:33:51 +0800 (WST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJO74096; Mon, 21 Jun 2004 10:34:42 -0400 (EDT) Message-ID: <40D6F202.4010708@cisco.com> Date: Mon, 21 Jun 2004 10:34:42 -0400 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: Henrik Leion Subject: Re: [SIMPLE] Authorization of resource list back-end subscriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple mailinglist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henrik Leion wrote: > Well, I just thought I'd toss in the idea. I believe that domains will be > small (office or home networks even) and that both inter-domain > subscriptions and resource-list subscriptions will be very common. I was > thinking in these lines: > > - If the ideas with filters, authorization rules and partial presence will > be implemented, how many users can there be on one presence-server? Parsing > xml-docs is quite more time-consuming than just forwarding requests. I too am worried about this. Something that prevents a PS from having to send a separate NOTIFY, with customized content, for every direct subscriber, including thost that arrive indirectly via a list, would be a good thing. But I'm not convinced you have found the right solution. > - How large parts of the resource-lists will actually come from the same > presence-server and how much is back-end subscriptions? > - If subscriptions are to be authorized using watcher-info notification and > XCAP, isn't it a bit boring that it just says "pres.example.com" instead of > at least saying what resource-list your presence is publicated on? Better > yet is that the winfo-file states the subscribers to the resource-lists. Jonathan addressed this point. I'm with him on it. >>- what kind of credential could the RLS have and provide when >>subscribing that authenticates it as the resource-list? > > Well, actually I don't know. But what difference is there between an RLS > authenticating itself to a presentity using some "sip:pres.example.com" URI, > than should it use "sip:adam-friends@lists.example.com"? > In either case the presentity have probably never heard of example.com > before. If it were to authenticate as itself, then I agree its likely that nobody would grant it authorization. Authenticating as the list itself is indeed an improvement over that, but not a great one, because authorizing it doesn't give me real control over who receives my presence. More on that below. >>- in case of private lists (e.g. I am the only one who subscribes to >>*my* buddy list) having credentials for my buddy list is no easier than >>having credentials for me. > > Yes, I was thinking in the lines of public lists; intranet address-lists, > conferences, discussion groups etc. But I'm under the impression that the > RLS does not use the presentities credentials when creating a back-end > subscription but instead acts on its own, "RLSes acts as a subscriber" > [event-list draft]. Again, Jonathan spoke to this. Using the ultimate subscriber's credentials is pretty important. *If* a list were *known* to be available to only a single subscriber (or known list of subscribers I suppose), then authorizing based on credentials for the list itself would perhaps be acceptable. (Though annoying.) E.g. If I had a pending subscription from: sip:JohnSmith-buddylist@rls.example.com and sip:JohnSmith@example.com is indeed a buddy of mine, and I am familiar with the example.com rls server and that buddy lists aren't shared, then I might be inclined to grant the subscription. >>- if the RLS server has lists L1 and L2 that both have a reference to >>presentity P, then it still can't use a single subscription to P and >>provide results to subscribers of both L1 and L2. > > Yes it could. > P.winfo would contain L1 and L2 along with all other watchers that are > interested in the presence of P. If P wants to check who actually subscribes > to L1 and L2, he would consult L1.winfo and L2.winfo. This is very different than the expected authorization model for presence subscriptions. Normally, P will not care about authorized watchers in P.winfo. Instead, all it will care about are those that are 'pending'. They are the watchers that want access to P's presence but that have neither been granted nor denied it. User P then either grants or denies them access, and never gives them another thought. In the case of L1 and L2, P has to decide whether to grant access the first time the server subscribes on behalf of each. User P can check who is currently watching L1 or L2 at that time, but that will say nothing about who may watch them at some other time. > Another idea is to add a namespace to winfo for resourcelists, now P can see > anybody subscribing to him directly, instead of just knowing that an RLS is > subscribing. This doesn't solve the problem. As a notifier, I don't want to have to recognize that a particular watcher is a list and then monitor the subscribers of that list to decide moment-by-moment what I am comfortable publishing to that set of watchers. And even if I was willing to, there would be race conditions so that what I publish could go to someone I didn't expect. For such a system to work at all, it would need to be based on who is *authorized* to watch the list, not who is currently watching it. And even then, it would be a bad system. The notifier would have to tailor the content published to the intersection of what it is willing to make available to any of the potential subscribers to the list. That isn't going to be very appealing to subscribers that would otherwise be able to see more. >>Well, maybe it *could* but that sounds really cumbersome, expensive, and >>not especially reliable. Can I ever safely decide what to disclose based >>on who I think is currently subscribing to that list, rather than who >>potentially *could* subscribe to it? > > But that's the whole idea behind presence authorization using winfo-lists, > isn't it? No. See above. > That you can trust the presence server that it only sends your > presence information to those watchers that are marked "active" in your > winfo-file. When new subscriptions come, the presence server will either > allow or disallow it judging from authorization rules, or otherwise set the > subscription-state to "pending" and let the presentity decide. > If you don't trust that the server will act this way in the future, send > less information. This is way to dynamic for making policy decisions. > Those present on a resource-list should be allowed to create resource-list > authorization rules appliable to their own presence. > L1 has two subscribers S1a and S1b. P may be authorized to create a rule in > L1.auth that always transforms his presence to appear offline to S1b, whilst > S1a will get P's true presence. > The authorization rules of a resource list should belong to the people on > it, at least in public applications, such as conference lists. But in a > black-list or buddylist application the idea is probably quite stupid. Well, that would solve some of the problems. But it presents serious issues of trust. Why should I believe that I can trust the RLS managing L1 to administer my policies? And mechanistically, I don't think I would want to deal with that kind of authorization manually. It sounds to me like that is a potential optimization that could be carried out among a set of mutually cooperating servers that have suitable mutual trust arrangements. In that case the user should not have to do anything special - the appropriate authorization rules would be shared among the servers. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 21 16:12:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24176 for ; Mon, 21 Jun 2004 16:12:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcV9P-0002Xo-Cp for simple-archive@ietf.org; Mon, 21 Jun 2004 16:12:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcV6z-0001b4-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 16:09:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcV4m-0000vc-02; Mon, 21 Jun 2004 16:07:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcUr9-0002Wt-IY; Mon, 21 Jun 2004 15:53:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUOj-0000Ir-C4; Mon, 21 Jun 2004 15:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUKp-00076K-Qr for simple@megatron.ietf.org; Mon, 21 Jun 2004 15:20: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 PAA19076 for ; Mon, 21 Jun 2004 15:20:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcUKo-0002CF-AA for simple@ietf.org; Mon, 21 Jun 2004 15:20:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcUJp-0001vV-00 for simple@ietf.org; Mon, 21 Jun 2004 15:19:01 -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 1BcUJ0-0001Nz-00 for simple@ietf.org; Mon, 21 Jun 2004 15:18:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2004 12:21:00 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5LJHW72000269; Mon, 21 Jun 2004 12:17:32 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJP03711; Mon, 21 Jun 2004 15:17:31 -0400 (EDT) Message-ID: <40D7344B.8070905@cisco.com> Date: Mon, 21 Jun 2004 15:17:31 -0400 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 Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> <1087828039.2162.2.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Hisham Khartabil , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > We're not expecting these URIs to have parameters normally, but > is there anything that prevents them from being provided? Not that I can see. Some parameters may be required. And in general unknown parameters must be ignored. That makes bogus use of them to get around uniqueness hard to avoid: sip:123@example.com sip:123@example.com;user=dialstring sip:123@example.com;foobar=1 sip:123@example.com;foobar=2 ... sip:123@example.com;foobar=999999999 Paul > RjS > > On Sun, 2004-06-20 at 21:33, Paul Kyzivat wrote: > >>Jonathan Rosenberg wrote: >> >>>Paul Kyzivat wrote: >>> >>> >>>>Well, its a great "feature" if the list is being used as a MESSAGE >>>>exploder. (Which may be a bit off topic here.) >>>> >>>>It gives me yet another way to cheaply generate spam and/or DoS >>>>attacks, by hammering the same recipient many times. >>> >>>Even if the same URI can appear only once, you might be able to hammer >>>the same recipient many times by using many different URI at the same host. >>> >>>If you want to prevent this attack, you need a more systematic way of >>>getting authorization for message receipt, as we discussed at the >>>interim. As such, I don't think this particular MUST/SHOULD decision >>>really hinges at all on the exploder question. >> >>I guess you are right, that it would be possible to get around the >>uniqueness issue by spinning variants on the same address, perhaps by >>adding a url parameter. >> >>I wasn't intending to be entirely serious here. >> >> 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 21 16:26:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25418 for ; Mon, 21 Jun 2004 16:26:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcVMk-0006Z6-8w for simple-archive@ietf.org; Mon, 21 Jun 2004 16:26:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcVLj-0006Eu-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 16:25:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcVKp-0005gj-00; Mon, 21 Jun 2004 16:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcV8e-0004ca-17; Mon, 21 Jun 2004 16:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUxO-0001oe-82 for simple@megatron.ietf.org; Mon, 21 Jun 2004 15:59: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 PAA23074 for ; Mon, 21 Jun 2004 15:59:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcUxN-0006aZ-10 for simple@ietf.org; Mon, 21 Jun 2004 15:59:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcUwV-0006Jj-00 for simple@ietf.org; Mon, 21 Jun 2004 15:58: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 1BcUvV-0005jD-00 for simple@ietf.org; Mon, 21 Jun 2004 15:57:57 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5LJufLp004981; Mon, 21 Jun 2004 14:56:41 -0500 Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices From: Robert Sparks To: Paul Kyzivat In-Reply-To: <40D7344B.8070905@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> <1087828039.2162.2.camel@localhost.localdomain> <40D7344B.8070905@cisco.com> Content-Type: text/plain Message-Id: <1087847596.2941.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 21 Jun 2004 14:53:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Hisham Khartabil , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Then is it sufficient to only specify the (tolower) canonicalization on hostport as Jonathan proposed? Parameter re-ordering leads to URI equivalence that is not bit-wise equivalence. (sip:a@b;p1=1;p2=2 == sip:a@b;p2=2;p1=1) Or is it sufficient to say that if you put URIs with parameters into one of these lists, then you should expect to deal with potential "duplicates"? RjS On Mon, 2004-06-21 at 14:17, Paul Kyzivat wrote: > Robert Sparks wrote: > > We're not expecting these URIs to have parameters normally, but > > is there anything that prevents them from being provided? > > Not that I can see. Some parameters may be required. And in general > unknown parameters must be ignored. That makes bogus use of them to get > around uniqueness hard to avoid: > > sip:123@example.com > sip:123@example.com;user=dialstring > sip:123@example.com;foobar=1 > sip:123@example.com;foobar=2 > ... > sip:123@example.com;foobar=999999999 > > Paul > > > RjS > > > > On Sun, 2004-06-20 at 21:33, Paul Kyzivat wrote: > > > >>Jonathan Rosenberg wrote: > >> > >>>Paul Kyzivat wrote: > >>> > >>> > >>>>Well, its a great "feature" if the list is being used as a MESSAGE > >>>>exploder. (Which may be a bit off topic here.) > >>>> > >>>>It gives me yet another way to cheaply generate spam and/or DoS > >>>>attacks, by hammering the same recipient many times. > >>> > >>>Even if the same URI can appear only once, you might be able to hammer > >>>the same recipient many times by using many different URI at the same host. > >>> > >>>If you want to prevent this attack, you need a more systematic way of > >>>getting authorization for message receipt, as we discussed at the > >>>interim. As such, I don't think this particular MUST/SHOULD decision > >>>really hinges at all on the exploder question. > >> > >>I guess you are right, that it would be possible to get around the > >>uniqueness issue by spinning variants on the same address, perhaps by > >>adding a url parameter. > >> > >>I wasn't intending to be entirely serious here. > >> > >> 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 > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 21 18:53:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12041 for ; Mon, 21 Jun 2004 18:53:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcXfr-0003Bf-ID for simple-archive@ietf.org; Mon, 21 Jun 2004 18:53:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXer-0002sg-00 for simple-archive@ietf.org; Mon, 21 Jun 2004 18:52:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcXdt-0002IY-00; Mon, 21 Jun 2004 18:51:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXOJ-0004IK-4o; Mon, 21 Jun 2004 18:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXE1-0001b8-Ia for simple@megatron.ietf.org; Mon, 21 Jun 2004 18:25: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 SAA10057 for ; Mon, 21 Jun 2004 18:25:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcXDz-0002M4-SO for simple@ietf.org; Mon, 21 Jun 2004 18:25:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXDF-00024z-00 for simple@ietf.org; Mon, 21 Jun 2004 18:24:26 -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 1BcXCU-0001jr-00 for simple@ietf.org; Mon, 21 Jun 2004 18:23:39 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2004 15:26:10 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5LMMxgI018412; Mon, 21 Jun 2004 15:22:59 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJP24202; Mon, 21 Jun 2004 18:22:58 -0400 (EDT) Message-ID: <40D75FC3.4070200@cisco.com> Date: Mon, 21 Jun 2004 18:22:59 -0400 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 Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> <1087828039.2162.2.camel@localhost.localdomain> <40D7344B.8070905@cisco.com> <1087847596.2941.20.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Hisham Khartabil , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I think I would just declare this a user problem to deal with rather than complicating things unnecessarily. Paul Robert Sparks wrote: > Then is it sufficient to only specify the (tolower) canonicalization > on hostport as Jonathan proposed? Parameter re-ordering leads to > URI equivalence that is not bit-wise equivalence. > (sip:a@b;p1=1;p2=2 == sip:a@b;p2=2;p1=1) > > Or is it sufficient to say that if you put URIs with parameters > into one of these lists, then you should expect to deal with > potential "duplicates"? > > RjS > > On Mon, 2004-06-21 at 14:17, Paul Kyzivat wrote: > >>Robert Sparks wrote: >> >>>We're not expecting these URIs to have parameters normally, but >>>is there anything that prevents them from being provided? >> >>Not that I can see. Some parameters may be required. And in general >>unknown parameters must be ignored. That makes bogus use of them to get >>around uniqueness hard to avoid: >> >> sip:123@example.com >> sip:123@example.com;user=dialstring >> sip:123@example.com;foobar=1 >> sip:123@example.com;foobar=2 >> ... >> sip:123@example.com;foobar=999999999 >> >>Paul >> >> >>>RjS >>> >>>On Sun, 2004-06-20 at 21:33, Paul Kyzivat wrote: >>> >>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>> >>>>> >>>>>>Well, its a great "feature" if the list is being used as a MESSAGE >>>>>>exploder. (Which may be a bit off topic here.) >>>>>> >>>>>>It gives me yet another way to cheaply generate spam and/or DoS >>>>>>attacks, by hammering the same recipient many times. >>>>> >>>>>Even if the same URI can appear only once, you might be able to hammer >>>>>the same recipient many times by using many different URI at the same host. >>>>> >>>>>If you want to prevent this attack, you need a more systematic way of >>>>>getting authorization for message receipt, as we discussed at the >>>>>interim. As such, I don't think this particular MUST/SHOULD decision >>>>>really hinges at all on the exploder question. >>>> >>>>I guess you are right, that it would be possible to get around the >>>>uniqueness issue by spinning variants on the same address, perhaps by >>>>adding a url parameter. >>>> >>>>I wasn't intending to be entirely serious here. >>>> >>>> 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 >>> >> > > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 22 13:29:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02254 for ; Tue, 22 Jun 2004 13:29:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcp5a-000708-2c for simple-archive@ietf.org; Tue, 22 Jun 2004 13:29:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcncQ-0000qH-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 11:55:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BclVM-0001gA-00; Tue, 22 Jun 2004 09:40:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BclHV-0007f8-M9; Tue, 22 Jun 2004 09:25:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BckoO-0002QG-EY; Tue, 22 Jun 2004 08:55:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcgDV-0003Vh-0v for simple@megatron.ietf.org; Tue, 22 Jun 2004 04:01: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 EAA15712 for ; Tue, 22 Jun 2004 04:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcgDS-000364-Gw for simple@ietf.org; Tue, 22 Jun 2004 04:01:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcgCV-0002np-00 for simple@ietf.org; Tue, 22 Jun 2004 04:00:16 -0400 Received: from epact.se ([192.36.138.128]) by ietf-mx with esmtp (Exim 4.12) id 1BcgC6-0002Vp-00 for simple@ietf.org; Tue, 22 Jun 2004 03:59:50 -0400 Received: from krypton (krypton.epact.se [192.36.138.36]) by epact.se (8.12.11/8.12.10) with SMTP id i5M7xKWX004853 for ; Tue, 22 Jun 2004 09:59:21 +0200 From: "Henrik Leion" To: "Simple mailinglist" Subject: RE: [SIMPLE] Authorization of resource list back-end subscriptions Date: Tue, 22 Jun 2004 10:02:08 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40D6F202.4010708@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hmm, I feel we're talking and thinking about different things. All I'm saying is that it could be useful to see in what context someone wants my presence info, resource-lists can be used not only to make subscribing easier - it could help a presentity group subscriptions and automate authorization. Resource-lists can be so much more than just a server-sided buddylist (where end-to-end authorization is undoubtedly best), think discussion-groups, conferences, games and future event packages. I'm not suggesting any changes in how subscribers are authenticated, only that more information is given to the presentity to help him set up authorization rules (to automate more, not less). If the presentity would like to challenge a subscription request, he would still identify the resource-list subscriber as usual. Consider this scenario: Bob (sip:Bob@bobs-company.com) is a member of these resource-lists: L1=Bobs-family@rls.example.com with 5 subscribers (Bob and his family) L2=Porsche-Owners@rls.example.com with 200 subscribers Bob would like to publish much info to his family, but very limited info to other Porsche-owners (say online status from his chat-client at home and his cell phone's geoloc info when he's driving his Porsche). Bob accepts the risks with sending geoloc info to strangers, because he thinks it's a nice way of meeting new friends and would like automate the authorization for members of that list. But when Bob gets a (back-end) subscription from pres.example.com, challenge it and finds out it's Alice@another.domain.com, he still doesn't know if she owns a Porsche, or if it's his cousin. If Bob instead gets a subscription from porshe-owners@rls.example.com (again initialized by Alice), he may be content with that, not caring about the identity of that particular Porshe-owner, and set his policies to automatically authorize this subscription. The ideas on writing resourcelist-subscribers in presentity watcher-info and allowing presentity to write authorization-rules for resource-lists are a bit far out, I'll admit, but if the resource-lists are made more visible, it would be possible for those software developers inclined. Although I never meant to suggest it, the possibility of having the RLS to authenticate itself, instead of forwarding the authentication request to the subscriber, is interesting (not annoying). The key is that if the presentity does not know the subscriber, an authentication would not be very informative. But if the owner of the list instead says "I will personally check that every subscriber is entitled to be on this list and kick out those that misbehave", and the subscribers trust him, they will have the possibility to automate authorization of strangers with more security. Check out the game Mogi (http://www.thefeature.com/article?articleid=100501) that could use Sip this way. /Henrik > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: den 21 juni 2004 16:35 > To: Henrik Leion > Cc: Simple mailinglist > Subject: Re: [SIMPLE] Authorization of resource list back-end > subscriptions > > > > > Henrik Leion wrote: > > Well, I just thought I'd toss in the idea. I believe that > domains will be > > small (office or home networks even) and that both inter-domain > > subscriptions and resource-list subscriptions will be very common. I was > > thinking in these lines: > > > > - If the ideas with filters, authorization rules and partial > presence will > > be implemented, how many users can there be on one > presence-server? Parsing > > xml-docs is quite more time-consuming than just forwarding requests. > > I too am worried about this. Something that prevents a PS from having to > send a separate NOTIFY, with customized content, for every direct > subscriber, including thost that arrive indirectly via a list, would be > a good thing. But I'm not convinced you have found the right solution. > > > - How large parts of the resource-lists will actually come > from the same > > presence-server and how much is back-end subscriptions? > > - If subscriptions are to be authorized using watcher-info > notification and > > XCAP, isn't it a bit boring that it just says > "pres.example.com" instead of > > at least saying what resource-list your presence is publicated > on? Better > > yet is that the winfo-file states the subscribers to the resource-lists. > > Jonathan addressed this point. I'm with him on it. > > >>- what kind of credential could the RLS have and provide when > >>subscribing that authenticates it as the resource-list? > > > > Well, actually I don't know. But what difference is there between an RLS > > authenticating itself to a presentity using some > "sip:pres.example.com" URI, > > than should it use "sip:adam-friends@lists.example.com"? > > In either case the presentity have probably never heard of example.com > > before. > > If it were to authenticate as itself, then I agree its likely that > nobody would grant it authorization. Authenticating as the list itself > is indeed an improvement over that, but not a great one, because > authorizing it doesn't give me real control over who receives my > presence. More on that below. > > >>- in case of private lists (e.g. I am the only one who subscribes to > >>*my* buddy list) having credentials for my buddy list is no easier than > >>having credentials for me. > > > > Yes, I was thinking in the lines of public lists; intranet > address-lists, > > conferences, discussion groups etc. But I'm under the > impression that the > > RLS does not use the presentities credentials when creating a back-end > > subscription but instead acts on its own, "RLSes acts as a subscriber" > > [event-list draft]. > > Again, Jonathan spoke to this. Using the ultimate subscriber's > credentials is pretty important. > > *If* a list were *known* to be available to only a single subscriber (or > known list of subscribers I suppose), then authorizing based on > credentials for the list itself would perhaps be acceptable. (Though > annoying.) E.g. If I had a pending subscription from: > > sip:JohnSmith-buddylist@rls.example.com > > and sip:JohnSmith@example.com is indeed a buddy of mine, and I am > familiar with the example.com rls server and that buddy lists aren't > shared, then I might be inclined to grant the subscription. > > >>- if the RLS server has lists L1 and L2 that both have a reference to > >>presentity P, then it still can't use a single subscription to P and > >>provide results to subscribers of both L1 and L2. > > > > Yes it could. > > P.winfo would contain L1 and L2 along with all other watchers that are > > interested in the presence of P. If P wants to check who > actually subscribes > > to L1 and L2, he would consult L1.winfo and L2.winfo. > > This is very different than the expected authorization model for > presence subscriptions. Normally, P will not care about authorized > watchers in P.winfo. Instead, all it will care about are those that are > 'pending'. They are the watchers that want access to P's presence but > that have neither been granted nor denied it. User P then either grants > or denies them access, and never gives them another thought. Ah, yes. That what the draft says. Thanks > > In the case of L1 and L2, P has to decide whether to grant access the > first time the server subscribes on behalf of each. User P can check who > is currently watching L1 or L2 at that time, but that will say nothing > about who may watch them at some other time. > > > Another idea is to add a namespace to winfo for resourcelists, > now P can see > > anybody subscribing to him directly, instead of just knowing > that an RLS is > > subscribing. > > This doesn't solve the problem. As a notifier, I don't want to have to > recognize that a particular watcher is a list and then monitor the > subscribers of that list to decide moment-by-moment what I am > comfortable publishing to that set of watchers. And even if I was > willing to, there would be race conditions so that what I publish could > go to someone I didn't expect > > For such a system to work at all, it would need to be based on who is > *authorized* to watch the list, not who is currently watching it. And > even then, it would be a bad system. The notifier would have to tailor > the content published to the intersection of what it is willing to make > available to any of the potential subscribers to the list. That isn't > going to be very appealing to subscribers that would otherwise be able > to see more. > > >>Well, maybe it *could* but that sounds really cumbersome, expensive, and > >>not especially reliable. Can I ever safely decide what to disclose based > >>on who I think is currently subscribing to that list, rather than who > >>potentially *could* subscribe to it? > > > > But that's the whole idea behind presence authorization using > winfo-lists, > > isn't it? > > No. See above. > > > That you can trust the presence server that it only sends your > > presence information to those watchers that are marked "active" in your > > winfo-file. When new subscriptions come, the presence server will either > > allow or disallow it judging from authorization rules, or > otherwise set the > > subscription-state to "pending" and let the presentity decide. > > If you don't trust that the server will act this way in the future, send > > less information. > > This is way to dynamic for making policy decisions. > > > Those present on a resource-list should be allowed to create > resource-list > > authorization rules appliable to their own presence. > > L1 has two subscribers S1a and S1b. P may be authorized to > create a rule in > > L1.auth that always transforms his presence to appear offline > to S1b, whilst > > S1a will get P's true presence. > > The authorization rules of a resource list should belong to the > people on > > it, at least in public applications, such as conference lists. But in a > > black-list or buddylist application the idea is probably quite stupid. > > Well, that would solve some of the problems. But it presents serious > issues of trust. Why should I believe that I can trust the RLS managing > L1 to administer my policies? > > And mechanistically, I don't think I would want to deal with that kind > of authorization manually. > > It sounds to me like that is a potential optimization that could be > carried out among a set of mutually cooperating servers that have > suitable mutual trust arrangements. In that case the user should not > have to do anything special - the appropriate authorization rules would > be shared among the servers. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 22 19:08:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07687 for ; Tue, 22 Jun 2004 19:08:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcuNs-0001oN-GM for simple-archive@ietf.org; Tue, 22 Jun 2004 19:08:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcuJI-0000Tc-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 19:04:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcuHz-0007gc-01; Tue, 22 Jun 2004 19:02:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuHE-0003Vt-SZ; Tue, 22 Jun 2004 19:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctmE-0007VX-0q; Tue, 22 Jun 2004 18:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcpjF-0005B6-GK for simple@megatron.ietf.org; Tue, 22 Jun 2004 14:10: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 OAA10213 for ; Tue, 22 Jun 2004 14:10:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcpjE-0006Ic-AZ for simple@ietf.org; Tue, 22 Jun 2004 14:10:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcouH-0004wy-00 for simple@ietf.org; Tue, 22 Jun 2004 13:18:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BcnCp-0005o9-00 for simple@ietf.org; Tue, 22 Jun 2004 11:29:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2004 11:34:46 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5MFSFW2000958; Tue, 22 Jun 2004 11:28:18 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJP75286; Tue, 22 Jun 2004 11:28:15 -0400 (EDT) Message-ID: <40D8500F.7030408@cisco.com> Date: Tue, 22 Jun 2004 11:28:15 -0400 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: Henrik Leion Subject: Re: [SIMPLE] Authorization of resource list back-end subscriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple mailinglist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henrik, I think you are conflating unrelated concepts. The fact that I subscribe to the porsche-owners list doesn't make me a porsche-owner. (In fact I may well aspire to be a porsche-owner by first being a porsche-thief!) So it would be pretty dumb of you to grant me permission to subscribe to your presence solely because I have subscribed to the porsche-owners list. What *might* make sense would be to find a way to share a single list for two uses - as a buddy list for subscribing to presence, and as a white list for *authorizing* subscription to presence. Then you might choose both to subscribe to porsche-owners, and to use the porsche-owners list as a white list for granting subscriptions to your presence. (There are of course technical issues with accomplishing that.) Paul Henrik Leion wrote: > Hmm, I feel we're talking and thinking about different things. > All I'm saying is that it could be useful to see in what context someone > wants my presence info, resource-lists can be used not only to make > subscribing easier - it could help a presentity group subscriptions and > automate authorization. > Resource-lists can be so much more than just a server-sided buddylist (where > end-to-end authorization is undoubtedly best), think discussion-groups, > conferences, games and future event packages. > > I'm not suggesting any changes in how subscribers are authenticated, only > that more information is given to the presentity to help him set up > authorization rules (to automate more, not less). > If the presentity would like to challenge a subscription request, he would > still identify the resource-list subscriber as usual. > > Consider this scenario: > Bob (sip:Bob@bobs-company.com) is a member of these resource-lists: > L1=Bobs-family@rls.example.com with 5 subscribers (Bob and his family) > L2=Porsche-Owners@rls.example.com with 200 subscribers > > Bob would like to publish much info to his family, but very limited info to > other Porsche-owners (say online status from his chat-client at home and his > cell phone's geoloc info when he's driving his Porsche). Bob accepts the > risks with sending geoloc info to strangers, because he thinks it's a nice > way of meeting new friends and would like automate the authorization for > members of that list. > > But when Bob gets a (back-end) subscription from pres.example.com, challenge > it and finds out it's Alice@another.domain.com, he still doesn't know if she > owns a Porsche, or if it's his cousin. > If Bob instead gets a subscription from porshe-owners@rls.example.com (again > initialized by Alice), he may be content with that, not caring about the > identity of that particular Porshe-owner, and set his policies to > automatically authorize this subscription. > > The ideas on writing resourcelist-subscribers in presentity watcher-info and > allowing presentity to write authorization-rules for resource-lists are a > bit far out, I'll admit, but if the resource-lists are made more visible, it > would be possible for those software developers inclined. > > Although I never meant to suggest it, the possibility of having the RLS to > authenticate itself, instead of forwarding the authentication request to the > subscriber, is interesting (not annoying). The key is that if the presentity > does not know the subscriber, an authentication would not be very > informative. But if the owner of the list instead says "I will personally > check that every subscriber is entitled to be on this list and kick out > those that misbehave", and the subscribers trust him, they will have the > possibility to automate authorization of strangers with more security. > Check out the game Mogi (http://www.thefeature.com/article?articleid=100501) > that could use Sip this way. > > /Henrik > > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: den 21 juni 2004 16:35 >>To: Henrik Leion >>Cc: Simple mailinglist >>Subject: Re: [SIMPLE] Authorization of resource list back-end >>subscriptions >> >> >> >> >>Henrik Leion wrote: >> >>>Well, I just thought I'd toss in the idea. I believe that >> >>domains will be >> >>>small (office or home networks even) and that both inter-domain >>>subscriptions and resource-list subscriptions will be very common. I was >>>thinking in these lines: >>> >>> - If the ideas with filters, authorization rules and partial >> >>presence will >> >>>be implemented, how many users can there be on one >> >>presence-server? Parsing >> >>>xml-docs is quite more time-consuming than just forwarding requests. >> >>I too am worried about this. Something that prevents a PS from having to >>send a separate NOTIFY, with customized content, for every direct >>subscriber, including thost that arrive indirectly via a list, would be >>a good thing. But I'm not convinced you have found the right solution. >> >> >>> - How large parts of the resource-lists will actually come >> >>from the same >> >>>presence-server and how much is back-end subscriptions? >>> - If subscriptions are to be authorized using watcher-info >> >>notification and >> >>>XCAP, isn't it a bit boring that it just says >> >>"pres.example.com" instead of >> >>>at least saying what resource-list your presence is publicated >> >>on? Better >> >>>yet is that the winfo-file states the subscribers to the resource-lists. >> >>Jonathan addressed this point. I'm with him on it. >> >> >>>>- what kind of credential could the RLS have and provide when >>>>subscribing that authenticates it as the resource-list? >>> >>>Well, actually I don't know. But what difference is there between an RLS >>>authenticating itself to a presentity using some >> >>"sip:pres.example.com" URI, >> >>>than should it use "sip:adam-friends@lists.example.com"? >>>In either case the presentity have probably never heard of example.com >>>before. >> >>If it were to authenticate as itself, then I agree its likely that >>nobody would grant it authorization. Authenticating as the list itself >>is indeed an improvement over that, but not a great one, because >>authorizing it doesn't give me real control over who receives my >>presence. More on that below. >> >> >>>>- in case of private lists (e.g. I am the only one who subscribes to >>>>*my* buddy list) having credentials for my buddy list is no easier than >>>>having credentials for me. >>> >>>Yes, I was thinking in the lines of public lists; intranet >> >>address-lists, >> >>>conferences, discussion groups etc. But I'm under the >> >>impression that the >> >>>RLS does not use the presentities credentials when creating a back-end >>>subscription but instead acts on its own, "RLSes acts as a subscriber" >>>[event-list draft]. >> >>Again, Jonathan spoke to this. Using the ultimate subscriber's >>credentials is pretty important. >> >>*If* a list were *known* to be available to only a single subscriber (or >>known list of subscribers I suppose), then authorizing based on >>credentials for the list itself would perhaps be acceptable. (Though >>annoying.) E.g. If I had a pending subscription from: >> >> sip:JohnSmith-buddylist@rls.example.com >> >>and sip:JohnSmith@example.com is indeed a buddy of mine, and I am >>familiar with the example.com rls server and that buddy lists aren't >>shared, then I might be inclined to grant the subscription. >> >> >>>>- if the RLS server has lists L1 and L2 that both have a reference to >>>>presentity P, then it still can't use a single subscription to P and >>>>provide results to subscribers of both L1 and L2. >>> >>>Yes it could. >>>P.winfo would contain L1 and L2 along with all other watchers that are >>>interested in the presence of P. If P wants to check who >> >>actually subscribes >> >>>to L1 and L2, he would consult L1.winfo and L2.winfo. >> >>This is very different than the expected authorization model for >>presence subscriptions. Normally, P will not care about authorized >>watchers in P.winfo. Instead, all it will care about are those that are >>'pending'. They are the watchers that want access to P's presence but >>that have neither been granted nor denied it. User P then either grants >>or denies them access, and never gives them another thought. > > > Ah, yes. That what the draft says. Thanks > > >>In the case of L1 and L2, P has to decide whether to grant access the >>first time the server subscribes on behalf of each. User P can check who >>is currently watching L1 or L2 at that time, but that will say nothing >>about who may watch them at some other time. >> >> >>>Another idea is to add a namespace to winfo for resourcelists, >> >>now P can see >> >>>anybody subscribing to him directly, instead of just knowing >> >>that an RLS is >> >>>subscribing. >> >>This doesn't solve the problem. As a notifier, I don't want to have to >>recognize that a particular watcher is a list and then monitor the >>subscribers of that list to decide moment-by-moment what I am >>comfortable publishing to that set of watchers. And even if I was >>willing to, there would be race conditions so that what I publish could >>go to someone I didn't expect >> >>For such a system to work at all, it would need to be based on who is >>*authorized* to watch the list, not who is currently watching it. And >>even then, it would be a bad system. The notifier would have to tailor >>the content published to the intersection of what it is willing to make >>available to any of the potential subscribers to the list. That isn't >>going to be very appealing to subscribers that would otherwise be able >>to see more. >> >> >>>>Well, maybe it *could* but that sounds really cumbersome, expensive, and >>>>not especially reliable. Can I ever safely decide what to disclose based >>>>on who I think is currently subscribing to that list, rather than who >>>>potentially *could* subscribe to it? >>> >>>But that's the whole idea behind presence authorization using >> >>winfo-lists, >> >>>isn't it? >> >>No. See above. >> >> > That you can trust the presence server that it only sends your >> >>>presence information to those watchers that are marked "active" in your >>>winfo-file. When new subscriptions come, the presence server will either >>>allow or disallow it judging from authorization rules, or >> >>otherwise set the >> >>>subscription-state to "pending" and let the presentity decide. >>>If you don't trust that the server will act this way in the future, send >>>less information. >> >>This is way to dynamic for making policy decisions. >> >> >>>Those present on a resource-list should be allowed to create >> >>resource-list >> >>>authorization rules appliable to their own presence. >>>L1 has two subscribers S1a and S1b. P may be authorized to >> >>create a rule in >> >>>L1.auth that always transforms his presence to appear offline >> >>to S1b, whilst >> >>>S1a will get P's true presence. >>>The authorization rules of a resource list should belong to the >> >>people on >> >>>it, at least in public applications, such as conference lists. But in a >>>black-list or buddylist application the idea is probably quite stupid. >> >>Well, that would solve some of the problems. But it presents serious >>issues of trust. Why should I believe that I can trust the RLS managing >>L1 to administer my policies? >> >>And mechanistically, I don't think I would want to deal with that kind >>of authorization manually. >> >>It sounds to me like that is a potential optimization that could be >>carried out among a set of mutually cooperating servers that have >>suitable mutual trust arrangements. In that case the user should not >>have to do anything special - the appropriate authorization rules would >>be shared among the servers. >> >> 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-bounces@ietf.org Tue Jun 22 19:10:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07943 for ; Tue, 22 Jun 2004 19:10:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcuPL-0002Og-NP for simple-archive@ietf.org; Tue, 22 Jun 2004 19:10:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcuKc-0000yC-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 19:05:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcuI9-0007hn-00; Tue, 22 Jun 2004 19:03:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuAj-0002Bg-Hm; Tue, 22 Jun 2004 18:55:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctm0-0007Kf-7E; Tue, 22 Jun 2004 18:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcpRS-00022v-5S for simple@megatron.ietf.org; Tue, 22 Jun 2004 13:52: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 NAA06966 for ; Tue, 22 Jun 2004 13:52:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcpRQ-00033z-Ut for simple@ietf.org; Tue, 22 Jun 2004 13:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcoDP-0005TU-00 for simple@ietf.org; Tue, 22 Jun 2004 12:33:46 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Bclnl-0004Jp-01 for simple@ietf.org; Tue, 22 Jun 2004 09:59:05 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i5MDmhZr025141; Tue, 22 Jun 2004 06:48:44 -0700 (PDT) Received: from [12.47.24.174] (sjc-vpn2-397.cisco.com [10.21.113.141]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APY83800; Tue, 22 Jun 2004 06:48:40 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 21 Jun 2004 21:43:57 -0500 From: Cullen Jennings To: Gunnar Hellstrom , "'Toip list'" , "'Mundra, Satish'" , "'Arnoud van Wijk'" , "'Paul E. Jones'" , Gregg Vanderheiden , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] Re: [Sipping] RE: text/T140 and audio/t140 was: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Dropped off sipping and avt and added simple mailing list... I like this list but I think you have one other thing you want. You want to make a protocol that actually gets build and deployed. The narrower the market is that is addressed by your solution or as it gets more complex to build, the less the odds are of it being build. IM is going to be build. Session mode IM is highly likely to be build. What would you need changed to the current requirements for session mode IM in SIMPLE for it to meet all of your requirements? I believe there are extr= a requirements, I=B9m just trying to figure out what they are so perhaps we can see if they can be addressed in IM. Cullen On 5/31/04 1:22 AM, "Gunnar Hellstrom" wrote: > By this response, I include the SIPPING group in our discussion. > So, introduction: We have created a new transport of real time text for > character-by-character conversational use, called audio/t140c ( in the d= rafts > sofar we called it audio/t140, but in order to distinguish it more easily= in > sdp and discussions we will now propose name change to audio/t140c ) >=20 > The purpose of this format is to take text reliably between two PSTN tran= sit > gateways when the connection is used for IP transit of PSTN calls. It is = said > to be a benefit for the big gateways if they can use the same RTP stream = for > everything - voice, text, modem, fax, DTMF. >=20 > So, this format is introduced in the revision of the rtp spec for text > conversation rfc2793 that we are working on in avt. > http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-04.txt >=20 > The earlier transport text/t140 is still there, and is still compatible w= ith > RFC2793, and is intended for both gateway and endpoint usage. >=20 > Now it turns out that some designers may have had an intention to start u= sing > the audio/t140c format in other applications than trunking PSTN calls, > involving residential gateways and even SIP endpoint terminals. That caus= ed a > flame of discussion in avt, because that idea seems to threaten the whole= idea > of orderly service provision in SIP networks. >=20 > Such discussions are not right placed in avt. There we make the transport > specifications and do not discuss deeply how these transports are going t= o be > included in network structures, or how they go together with ambitions to > offer ambitious new services with SIP. >=20 > The right place for the discussion may be sipping or mmusic, and also in > external groups picking up SIP and putting profiles and usage conventions= on > it.=20 >=20 > We have concluded that real time text is a medium in its own right, that = needs > to be available simultaneously with voice in new networks. There is a low > functionality implementation of text in PSTN, but we do not want its > limitations to influence the service provision in SIP. But we want to off= er > gatewaying to it just as SIP voice telephony offers gatewaying to PSTN vo= ice > telephony. >=20 > The important functional goals we want to reach with text in SIP are at l= east > the following:=20 >=20 > 1.Truly simultaneous text, voice and video. >=20 > 2. Two way simultaneous transmission with a character-by-character feel= ing. >=20 > 3. Internationally usable character set. >=20 > 4. Capacity for transmission as fast as text can be produced by a typer= and > an automatic voice-to-text application - 30 characters per second. >=20 > 5. Possibility to participate in managed conferences. >=20 > 6. Good reliability and indication of rare loss to the user. >=20 > 7. Good security >=20 > 8. Declaration of the intention to use text in a session, and using tha= t > knowledge in allocating resources for the call >=20 > 9. Declaration of preference to use text as the main medium in a call, = and > using that knowledge in routing calls. >=20 > 10. Request to invoke text <-> voice transcoding services, and routing = of > the calls properly for that. >=20 > 11. Offering text alternatives to Interactive Voice Response systems >=20 > 12. Routing of emergency calls to agents used to handling text calls. >=20 > 13. Implenmentation in most SIP devices with interoperability between t= hem. >=20 > 14. Smooth ways to interoperate with conversational text in other netwo= rks, > e.g. PSTN. >=20 > RFC3351 expresses some of these goals, and text is mentioned in many plac= es in > IETF specs. E.g. megaco requirements. rfc2793, rfc2793bis, sipping-toip, > sdp-new-16, avt-emergency, sipdev, callee-caps, transcoding. >=20 > If text is not always declared as text in sdp, when SIP endpoints and > residential gateways are involved in the sessions, we have little chance = to > meet all the ambitions. That is the threat we see when designers coming f= rom > the voice side start to think that they can use audio/t140c outside its > original application in the big trunking gateways. >=20 > The question to the sipping group who are new to this question is: Where = are > there strong enough forces to encourage implementation of SIP in a way so= that > all good features that are within reach from consistent application of SI= P are > not spoiled by making shortcuts and imitating the limitations from the vo= ice > dominated PSTN? >=20 >=20 >=20 > Regards >=20 > Gunnar=20 >=20 > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >>=20 >> -----Original Message----- >> From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On Beha= lf Of >> Gregg Vanderheiden >> Sent: Monday, May 31, 2004 6:25 AM >> To: 'Paul E. Jones'; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; 'Mundra, >> Satish'; 'avt IETF'; 'Toip list' >> Subject: RE: text/T140 and audio/t140 was: [avt] Comments/questions on >> draft-ietf-avt-rfc2793bis-04 >>=20 >>=20 >>=20 >>=20 >> Hmmm >>=20 >>=20 >>=20 >> If we don't change from audio to T140-IP at all the fringes of the IP >> network =AD then we risk all the problems inherent in TTY over IP and mak= e it >> very hard to move off of TTY in the future since it will be embedded in= . >>=20 >>=20 >>=20 >> Yes? >>=20 >>=20 >>=20 >>=20 >> Gregg >>=20 >> -- ------------------------------ >> Gregg C Vanderheiden Ph.D. >> Professor - Ind. Engr. & BioMed Engr. >> Director - Trace R & D Center >> University of Wisconsin-Madison >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Beh= alf >> Of Paul E. Jones >> Sent: Wednesday, May 26, 2004 3:23 PM >> To: Arnoud van Wijk; 'Gunnar Hellstrom'; 'Mundra, Satish'; 'avt IETF'; = 'Toip >> list' >> Subject: Re: text/T140 and audio/t140 was: [avt] Comments/questions on >> draft-ietf-avt-rfc2793bis-04 >>=20 >>=20 >>=20 >>=20 >>=20 >> Arnoud, >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> You are correct that not every residential GW will be used to call to a= PSTN >> GW, but I will argue that most calls will be to PSTN GWs for a period o= f >> time. After that period of time, we will see a healthy mix of on-net a= nd >> off-net calls, ultimately ending up with most calls being on-net. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> However, anytime that we connect a PSTN textphone to a residential gate= way, >> there is a very high degree of probability that the user will call anot= her >> user who is also using a PSTN textphone, either connected to the PSTN o= r >> hanging off of a residential gateway. So, the use of audio/t140 would = still >> be quite useful and would probably be the likely mode for exchanging te= xt. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> I am not suggesting that the residential GWs not support text/t140-- th= ey >> should for the benefit of interconnecting to pocket PCs or personal >> computers running software that allows one to truly have simultaneous v= oice, >> video, and/or text. Likewise, we should see PSTN gateways support >> text/t140, too. I just think that any device which interconnects with = a >> legacy TTY will likely propose audio/t140 and I think that's OK. If th= at >> device calls a user on a PC, then the mode of communication should be >> switched to text/t140-- and SIP offers that kind of negotiation. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Paul >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>>=20 >>>=20 >>>=20 >>> From: Arnoud van Wijk >>>=20 >>>=20 >>>=20 >>> To: 'Gunnar Hellstrom' ; 'Mundra, >>> Satish' ; 'Paul E. Jones' >>> ; 'avt IETF' ; '= Toip >>> list' >>>=20 >>>=20 >>>=20 >>> Sent: Wednesday, May 26, 2004 3:57 PM >>>=20 >>>=20 >>>=20 >>> Subject: RE: text/T140 and audio/t140 was: [avt] Comments/questions on >>> draft-ietf-avt-rfc2793bis-04 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Gunnar.. >>>=20 >>> Amen! >>>=20 >>>=20 >>>=20 >>> That is also my feeling. >>>=20 >>> That is why I am trying to limit the uses for audio/t140. >>>=20 >>> I still feel unhappy about audio/t140. >>>=20 >>> And the answers from others that a residental gateway will use audio/t= 140 >>> makes me uneasy. >>>=20 >>>=20 >>>=20 >>> The argument that such residental gateway will be used for mainly PSTN >>> calls=8A.I do not agree. It can also be through a VoIP server at your lo= cal >>> network provider. And those can be interconnected with other local ISP= s and >>> such. It is not default to PSTN. (right now in Holland, VoIP services = are >>> starting, with a residental gateway/modem and it is not aimed pstn onl= y). >>>=20 >>> So lets keep the freedom of the IP telephony and focus on text/t140 fo= r >>> residental gateways! >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Greetz >>>=20 >>>=20 >>>=20 >>> Arnoud >>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 22 19:36:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11160 for ; Tue, 22 Jun 2004 19:36:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcuol-0001RP-F6 for simple-archive@ietf.org; Tue, 22 Jun 2004 19:36:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcuei-0006my-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 19:26:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcuYH-0004tq-00; Tue, 22 Jun 2004 19:19:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuRQ-0006Fn-SB; Tue, 22 Jun 2004 19:12:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctnR-00083g-4k; Tue, 22 Jun 2004 18:31:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqL3-0003H5-VB for simple@megatron.ietf.org; Tue, 22 Jun 2004 14:49:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17324 for ; Tue, 22 Jun 2004 14:49:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqL2-0005fl-Pu for simple@ietf.org; Tue, 22 Jun 2004 14:49:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcq87-0002sa-00 for simple@ietf.org; Tue, 22 Jun 2004 14:36:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Bcpil-0006Ae-00 for simple@ietf.org; Tue, 22 Jun 2004 14:10:11 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2004 14:16:07 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5MI9cX4017603; Tue, 22 Jun 2004 14:09:38 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJP92830; Tue, 22 Jun 2004 14:09:37 -0400 (EDT) Message-ID: <40D875E1.3030300@cisco.com> Date: Tue, 22 Jun 2004 14:09:37 -0400 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: Jonathan Rosenberg Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> <1087828039.2162.2.camel@localhost.localdomain> <40D7344B.8070905@cisco.com> <1087847596.2941.20.camel@localhost.localdomain> <40D75FC3.4070200@cisco.com> <40D867E4.3030500@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Hisham Khartabil , Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan, I'm not understanding you. I guess you are just saying that URI cannonicalization is *defined* as part of registration. And then you are suggesting it *should* be used in xcap list manip??? Maybe SHOULD is ok. But then the SHOULD will have to be ignored if the canonicalization removes parameters that are important (such as user=phone.) (The cannonicalization could be a problem with REGISTER, but probably not in practice, since it only applies to AORs, and its hard to think of a case where two AORs only differ by a URI parameter.) Paul Jonathan Rosenberg wrote: > We already do URI canonicalization. Its defined in section on register > processing in RFC 3261: > > 5. The registrar extracts the address-of-record from the To header > field of the request. If the address-of-record is not valid > for the domain in the Request-URI, the registrar MUST send a > 404 (Not Found) response and skip the remaining steps. The URI > MUST then be converted to a canonical form. To do that, all > URI parameters MUST be removed (including the user-param), and > any escaped characters MUST be converted to their unescaped > form. The result serves as an index into the list of bindings. > > > I still think we should say that you SHOULD basically follow this > canonicalization, followed by tolower() on the domain part, which would > then allow for case-sensitive string compare to work. This > canonicalization would be done by the clients. > > -Jonathan R. > > > > Paul Kyzivat wrote: > >> I think I would just declare this a user problem to deal with rather >> than complicating things unnecessarily. >> >> Paul >> >> Robert Sparks wrote: >> >>> Then is it sufficient to only specify the (tolower) canonicalization >>> on hostport as Jonathan proposed? Parameter re-ordering leads to >>> URI equivalence that is not bit-wise equivalence. >>> (sip:a@b;p1=1;p2=2 == sip:a@b;p2=2;p1=1) >>> >>> Or is it sufficient to say that if you put URIs with parameters >>> into one of these lists, then you should expect to deal with >>> potential "duplicates"? >>> >>> RjS >>> >>> On Mon, 2004-06-21 at 14:17, Paul Kyzivat wrote: >>> >>>> Robert Sparks wrote: >>>> >>>>> We're not expecting these URIs to have parameters normally, but >>>>> is there anything that prevents them from being provided? >>>> >>>> >>>> >>>> Not that I can see. Some parameters may be required. And in general >>>> unknown parameters must be ignored. That makes bogus use of them to >>>> get around uniqueness hard to avoid: >>>> >>>> sip:123@example.com >>>> sip:123@example.com;user=dialstring >>>> sip:123@example.com;foobar=1 >>>> sip:123@example.com;foobar=2 >>>> ... >>>> sip:123@example.com;foobar=999999999 >>>> >>>> Paul >>>> >>>> >>>>> RjS >>>>> >>>>> On Sun, 2004-06-20 at 21:33, Paul Kyzivat wrote: >>>>> >>>>> >>>>>> Jonathan Rosenberg wrote: >>>>>> >>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Well, its a great "feature" if the list is being used as a >>>>>>>> MESSAGE exploder. (Which may be a bit off topic here.) >>>>>>>> >>>>>>>> It gives me yet another way to cheaply generate spam and/or DoS >>>>>>>> attacks, by hammering the same recipient many times. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Even if the same URI can appear only once, you might be able to >>>>>>> hammer the same recipient many times by using many different URI >>>>>>> at the same host. >>>>>>> >>>>>>> If you want to prevent this attack, you need a more systematic >>>>>>> way of getting authorization for message receipt, as we discussed >>>>>>> at the interim. As such, I don't think this particular >>>>>>> MUST/SHOULD decision really hinges at all on the exploder question. >>>>>> >>>>>> >>>>>> >>>>>> I guess you are right, that it would be possible to get around the >>>>>> uniqueness issue by spinning variants on the same address, perhaps >>>>>> by adding a url parameter. >>>>>> >>>>>> I wasn't intending to be entirely serious here. >>>>>> >>>>>> 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 >>>>> >>>> >>> >>> >>> _______________________________________________ >>> 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-bounces@ietf.org Tue Jun 22 19:38:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11514 for ; Tue, 22 Jun 2004 19:38:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcuqI-0001jr-4C for simple-archive@ietf.org; Tue, 22 Jun 2004 19:38:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcugM-0007B4-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 19:28:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcuYX-0005Fp-03; Tue, 22 Jun 2004 19:19:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuNF-0005CT-Cb; Tue, 22 Jun 2004 19:08:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctmn-0007tM-7W; Tue, 22 Jun 2004 18:30:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcq6n-0000Pz-Hj for simple@megatron.ietf.org; Tue, 22 Jun 2004 14:35: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 OAA14069 for ; Tue, 22 Jun 2004 14:34:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcq6m-0002eK-HZ for simple@ietf.org; Tue, 22 Jun 2004 14:35:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcpg6-0005pS-00 for simple@ietf.org; Tue, 22 Jun 2004 14:07:28 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcood-0003mi-00 for simple@ietf.org; Tue, 22 Jun 2004 13:12:11 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5MHAKbo028728; Tue, 22 Jun 2004 13:10:21 -0400 (EDT) Message-ID: <40D867E4.3030500@dynamicsoft.com> Date: Tue, 22 Jun 2004 13:09:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> <1087828039.2162.2.camel@localhost.localdomain> <40D7344B.8070905@cisco.com> <1087847596.2941.20.camel@localhost.localdomain> <40D75FC3.4070200@cisco.com> In-Reply-To: <40D75FC3.4070200@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Hisham Khartabil , Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We already do URI canonicalization. Its defined in section on register processing in RFC 3261: 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. I still think we should say that you SHOULD basically follow this canonicalization, followed by tolower() on the domain part, which would then allow for case-sensitive string compare to work. This canonicalization would be done by the clients. -Jonathan R. Paul Kyzivat wrote: > I think I would just declare this a user problem to deal with rather > than complicating things unnecessarily. > > Paul > > Robert Sparks wrote: > >> Then is it sufficient to only specify the (tolower) canonicalization >> on hostport as Jonathan proposed? Parameter re-ordering leads to >> URI equivalence that is not bit-wise equivalence. >> (sip:a@b;p1=1;p2=2 == sip:a@b;p2=2;p1=1) >> >> Or is it sufficient to say that if you put URIs with parameters >> into one of these lists, then you should expect to deal with >> potential "duplicates"? >> >> RjS >> >> On Mon, 2004-06-21 at 14:17, Paul Kyzivat wrote: >> >>> Robert Sparks wrote: >>> >>>> We're not expecting these URIs to have parameters normally, but >>>> is there anything that prevents them from being provided? >>> >>> >>> Not that I can see. Some parameters may be required. And in general >>> unknown parameters must be ignored. That makes bogus use of them to >>> get around uniqueness hard to avoid: >>> >>> sip:123@example.com >>> sip:123@example.com;user=dialstring >>> sip:123@example.com;foobar=1 >>> sip:123@example.com;foobar=2 >>> ... >>> sip:123@example.com;foobar=999999999 >>> >>> Paul >>> >>> >>>> RjS >>>> >>>> On Sun, 2004-06-20 at 21:33, Paul Kyzivat wrote: >>>> >>>> >>>>> Jonathan Rosenberg wrote: >>>>> >>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Well, its a great "feature" if the list is being used as a >>>>>>> MESSAGE exploder. (Which may be a bit off topic here.) >>>>>>> >>>>>>> It gives me yet another way to cheaply generate spam and/or DoS >>>>>>> attacks, by hammering the same recipient many times. >>>>>> >>>>>> >>>>>> Even if the same URI can appear only once, you might be able to >>>>>> hammer the same recipient many times by using many different URI >>>>>> at the same host. >>>>>> >>>>>> If you want to prevent this attack, you need a more systematic way >>>>>> of getting authorization for message receipt, as we discussed at >>>>>> the interim. As such, I don't think this particular MUST/SHOULD >>>>>> decision really hinges at all on the exploder question. >>>>> >>>>> >>>>> I guess you are right, that it would be possible to get around the >>>>> uniqueness issue by spinning variants on the same address, perhaps >>>>> by adding a url parameter. >>>>> >>>>> I wasn't intending to be entirely serious here. >>>>> >>>>> 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 >>>> >>> >> >> >> _______________________________________________ >> 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-bounces@ietf.org Tue Jun 22 21:37:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23153 for ; Tue, 22 Jun 2004 21:37:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcwha-00075d-FB for simple-archive@ietf.org; Tue, 22 Jun 2004 21:37:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcvx8-0007J7-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 20:49:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcvT6-0002Db-00; Tue, 22 Jun 2004 20:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctoq-0008Nd-Dv; Tue, 22 Jun 2004 18:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcsC1-0005j9-Fy for simple@megatron.ietf.org; Tue, 22 Jun 2004 16:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27456 for ; Tue, 22 Jun 2004 16:48:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcsBx-0002PO-K3 for simple@ietf.org; Tue, 22 Jun 2004 16:48:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcsB0-00022V-00 for simple@ietf.org; Tue, 22 Jun 2004 16:47:32 -0400 Received: from av7-1-sn1.fre.skanova.net ([81.228.11.113]) by ietf-mx with esmtp (Exim 4.12) id 1BcsA7-0001KP-00 for simple@ietf.org; Tue, 22 Jun 2004 16:46:35 -0400 Received: by av7-1-sn1.fre.skanova.net (Postfix, from userid 502) id 04ECA37E94; Tue, 22 Jun 2004 22:46:05 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-1-sn1.fre.skanova.net (Postfix) with ESMTP id E876137E51; Tue, 22 Jun 2004 22:46:04 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 8F53737E51; Tue, 22 Jun 2004 22:46:04 +0200 (CEST) From: "Gunnar Hellstrom" To: "Cullen Jennings" , "'Toip list'" , "'Mundra, Satish'" , "'Arnoud van Wijk'" , "'Paul E. Jones'" , "Gregg Vanderheiden" , Date: Tue, 22 Jun 2004 22:46:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: [avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cullen and all, Thanks for taking the discussion on real time text conversation into SIMP= LE. So far, I have regarded SIMPLE to be a messaging protocol, that handles a= medium level of timing requirements with complete messages in video, text, voice and imag= es. And Server based? Right? It definitely serves its purpose very well, and I really wish it will cre= ate some openness in the messaging world. What we have in avt and sipping in the text/t140 (rfc2793 and RFC2793bis = ) is a real time character-by-character text protocol, ready to flow in parallell to voice= and video in a regular Multimedia IP call. Based on RTP, but with good reliability. It has been proven that it is needed as a companion to the voice and vide= o paths of phone calls. Of course we want to see it more implemented to give full benefit to user= s who need or want text in the calls. It is so easy to implement. It uses all the same = mechanisms as the other real time media in the call. I see multimedia divided in at least three time relations. 1. Real time conversation. With video, text and voice flowing in real tim= e straight between two terminals. 2. Messaging. Compose a message and transmit. Usually via a server. SIMPL= E, SMS. 3. Stored and editied multimedia for retrieval or broadcasting. Cullen, you indicate that you think it would be easier to get to widespre= ad implementation by making SIMPLE handle character-by-character transmission, than by maki= ng the videophone producers add the real time text RTP? Why, and would it not be a complica= ted mixed protocol for a call, with straight SIP call establishment for the video a= nd voice media, and then involving SIMPLE and its server for the text part??????????? Is it not more straightforward to just add another RTP medium to the call= ? It is already proven, implementations exist, the medium flows wherever the other media = flows. Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Tuesday, June 22, 2004 4:44 AM >To: Gunnar Hellstrom; 'Toip list'; 'Mundra, Satish'; 'Arnoud van Wijk'; >'Paul E. Jones'; Gregg Vanderheiden; simple@ietf.org >Subject: Re: [Sipping] RE: text/T140 and audio/t140 was: >[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > >Dropped off sipping and avt and added simple mailing list... > >I like this list but I think you have one other thing you want. You want= to >make a protocol that actually gets build and deployed. The narrower the >market is that is addressed by your solution or as it gets more complex = to >build, the less the odds are of it being build. IM is going to be build. >Session mode IM is highly likely to be build. > >What would you need changed to the current requirements for session mode= IM >in SIMPLE for it to meet all of your requirements? I believe there are e= xtra >requirements, I=B9m just trying to figure out what they are so perhaps w= e can >see if they can be addressed in IM. > >Cullen > > >On 5/31/04 1:22 AM, "Gunnar Hellstrom" wro= te: > >> By this response, I include the SIPPING group in our discussion. >> So, introduction: We have created a new transport of real time text fo= r >> character-by-character conversational use, called audio/t140c ( in th= e drafts >> sofar we called it audio/t140, but in order to distinguish it more eas= ily in >> sdp and discussions we will now propose name change to audio/t140c ) >> >> The purpose of this format is to take text reliably between two PSTN t= ransit >> gateways when the connection is used for IP transit of PSTN calls. It = is said >> to be a benefit for the big gateways if they can use the same RTP stre= am for >> everything - voice, text, modem, fax, DTMF. >> >> So, this format is introduced in the revision of the rtp spec for text >> conversation rfc2793 that we are working on in avt. >> http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-04.txt >> >> The earlier transport text/t140 is still there, and is still compatibl= e with >> RFC2793, and is intended for both gateway and endpoint usage. >> >> Now it turns out that some designers may have had an intention to star= t using >> the audio/t140c format in other applications than trunking PSTN calls, >> involving residential gateways and even SIP endpoint terminals. That c= aused a >> flame of discussion in avt, because that idea seems to threaten the wh= ole idea >> of orderly service provision in SIP networks. >> >> Such discussions are not right placed in avt. There we make the transp= ort >> specifications and do not discuss deeply how these transports are goin= g to be >> included in network structures, or how they go together with ambitions= to >> offer ambitious new services with SIP. >> >> The right place for the discussion may be sipping or mmusic, and also = in >> external groups picking up SIP and putting profiles and usage conventi= ons on >> it. >> >> We have concluded that real time text is a medium in its own right, th= at needs >> to be available simultaneously with voice in new networks. There is a = low >> functionality implementation of text in PSTN, but we do not want its >> limitations to influence the service provision in SIP. But we want to = offer >> gatewaying to it just as SIP voice telephony offers gatewaying to PSTN= voice >> telephony. >> >> The important functional goals we want to reach with text in SIP are a= t least >> the following: >> >> 1.Truly simultaneous text, voice and video. >> >> 2. Two way simultaneous transmission with a character-by-character f= eeling. >> >> 3. Internationally usable character set. >> >> 4. Capacity for transmission as fast as text can be produced by a ty= per and >> an automatic voice-to-text application - 30 characters per second. >> >> 5. Possibility to participate in managed conferences. >> >> 6. Good reliability and indication of rare loss to the user. >> >> 7. Good security >> >> 8. Declaration of the intention to use text in a session, and using = that >> knowledge in allocating resources for the call >> >> 9. Declaration of preference to use text as the main medium in a cal= l, and >> using that knowledge in routing calls. >> >> 10. Request to invoke text <-> voice transcoding services, and routi= ng of >> the calls properly for that. >> >> 11. Offering text alternatives to Interactive Voice Response systems >> >> 12. Routing of emergency calls to agents used to handling text calls= . >> >> 13. Implenmentation in most SIP devices with interoperability betwee= n them. >> >> 14. Smooth ways to interoperate with conversational text in other ne= tworks, >> e.g. PSTN. >> >> RFC3351 expresses some of these goals, and text is mentioned in many p= laces in >> IETF specs. E.g. megaco requirements. rfc2793, rfc2793bis, sipping-toi= p, >> sdp-new-16, avt-emergency, sipdev, callee-caps, transcoding. >> >> If text is not always declared as text in sdp, when SIP endpoints and >> residential gateways are involved in the sessions, we have little chan= ce to >> meet all the ambitions. That is the threat we see when designers comin= g from >> the voice side start to think that they can use audio/t140c outside it= s >> original application in the big trunking gateways. >> >> The question to the sipping group who are new to this question is: Whe= re are >> there strong enough forces to encourage implementation of SIP in a way= so that >> all good features that are within reach from consistent application of= SIP are >> not spoiled by making shortcuts and imitating the limitations from the= voice >> dominated PSTN? >> >> >> >> Regards >> >> Gunnar >> >> ------------------------------------------- >> Gunnar Hellstr=F6m >> Omnitor AB >> Renathv=E4gen 2 >> SE 121 37 Johanneshov >> SWEDEN >> +46 8 556 002 03 >> Mob: +46 708 204 288 >> www.omnitor.se >> Gunnar.Hellstrom@Omnitor.se >> -------------------------------------------- >> >>> >>> -----Original Message----- >>> From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On B= ehalf Of >>> Gregg Vanderheiden >>> Sent: Monday, May 31, 2004 6:25 AM >>> To: 'Paul E. Jones'; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; 'Mundra, >>> Satish'; 'avt IETF'; 'Toip list' >>> Subject: RE: text/T140 and audio/t140 was: [avt] Comments/questions = on >>> draft-ietf-avt-rfc2793bis-04 >>> >>> >>> >>> >>> Hmmm >>> >>> >>> >>> If we don't change from audio to T140-IP at all the fringes of the I= P >>> network =AD then we risk all the problems inherent in TTY over IP an= d make it >>> very hard to move off of TTY in the future since it will be embedded= in. >>> >>> >>> >>> Yes? >>> >>> >>> >>> >>> Gregg >>> >>> -- ------------------------------ >>> Gregg C Vanderheiden Ph.D. >>> Professor - Ind. Engr. & BioMed Engr. >>> Director - Trace R & D Center >>> University of Wisconsin-Madison >>> >>> >>> >>> >>> >>> >>> >>> From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On = Behalf >>> Of Paul E. Jones >>> Sent: Wednesday, May 26, 2004 3:23 PM >>> To: Arnoud van Wijk; 'Gunnar Hellstrom'; 'Mundra, Satish'; 'avt IETF= '; 'Toip >>> list' >>> Subject: Re: text/T140 and audio/t140 was: [avt] Comments/questions = on >>> draft-ietf-avt-rfc2793bis-04 >>> >>> >>> >>> >>> >>> Arnoud, >>> >>> >>> >>> >>> >>> >>> >>> You are correct that not every residential GW will be used to call t= o a PSTN >>> GW, but I will argue that most calls will be to PSTN GWs for a perio= d of >>> time. After that period of time, we will see a healthy mix of on-ne= t and >>> off-net calls, ultimately ending up with most calls being on-net. >>> >>> >>> >>> >>> >>> >>> >>> However, anytime that we connect a PSTN textphone to a residential g= ateway, >>> there is a very high degree of probability that the user will call a= nother >>> user who is also using a PSTN textphone, either connected to the PST= N or >>> hanging off of a residential gateway. So, the use of audio/t140 wou= ld still >>> be quite useful and would probably be the likely mode for exchanging= text. >>> >>> >>> >>> >>> >>> >>> >>> I am not suggesting that the residential GWs not support text/t140--= they >>> should for the benefit of interconnecting to pocket PCs or personal >>> computers running software that allows one to truly have simultaneou= s voice, >>> video, and/or text. Likewise, we should see PSTN gateways support >>> text/t140, too. I just think that any device which interconnects wi= th a >>> legacy TTY will likely propose audio/t140 and I think that's OK. If= that >>> device calls a user on a PC, then the mode of communication should b= e >>> switched to text/t140-- and SIP offers that kind of negotiation. >>> >>> >>> >>> >>> >>> >>> >>> Paul >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> >>>> >>>> From: Arnoud van Wijk >>>> >>>> >>>> >>>> To: 'Gunnar Hellstrom' ; 'Mund= ra, >>>> Satish' ; 'Paul E. Jones' >>>> ; 'avt IETF' = ; 'Toip >>>> list' >>>> >>>> >>>> >>>> Sent: Wednesday, May 26, 2004 3:57 PM >>>> >>>> >>>> >>>> Subject: RE: text/T140 and audio/t140 was: [avt] Comments/questions= on >>>> draft-ietf-avt-rfc2793bis-04 >>>> >>>> >>>> >>>> >>>> >>>> Gunnar.. >>>> >>>> Amen! >>>> >>>> >>>> >>>> That is also my feeling. >>>> >>>> That is why I am trying to limit the uses for audio/t140. >>>> >>>> I still feel unhappy about audio/t140. >>>> >>>> And the answers from others that a residental gateway will use audi= o/t140 >>>> makes me uneasy. >>>> >>>> >>>> >>>> The argument that such residental gateway will be used for mainly P= STN >>>> calls=8A.I do not agree. It can also be through a VoIP server at yo= ur local >>>> network provider. And those can be interconnected with other local = ISPs and >>>> such. It is not default to PSTN. (right now in Holland, VoIP servic= es are >>>> starting, with a residental gateway/modem and it is not aimed pstn = only). >>>> >>>> So lets keep the freedom of the IP telephony and focus on text/t140= for >>>> residental gateways! >>>> >>>> >>>> >>>> >>>> >>>> Greetz >>>> >>>> >>>> >>>> Arnoud >>>> >>>> >>>> >>>> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 23 02:06:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11997 for ; Wed, 23 Jun 2004 02:06:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd0tu-0002wh-UY for simple-archive@ietf.org; Wed, 23 Jun 2004 02:06:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcxgv-0006Zp-00 for simple-archive@ietf.org; Tue, 22 Jun 2004 22:40:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcw7B-0001f1-00; Tue, 22 Jun 2004 20:59:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bcw7A-0008Gt-29; Tue, 22 Jun 2004 20:59:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcvsH-0000sE-OM; Tue, 22 Jun 2004 20:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcv1R-0001x1-Cy for simple@megatron.ietf.org; Tue, 22 Jun 2004 19:49: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 TAA12820 for ; Tue, 22 Jun 2004 19:49:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcv1P-0004DZ-Rp for simple@ietf.org; Tue, 22 Jun 2004 19:49:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcuos-0001St-00 for simple@ietf.org; Tue, 22 Jun 2004 19:36:54 -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 1Bcuer-0006fn-01 for simple@ietf.org; Tue, 22 Jun 2004 19:26:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2004 16:29:30 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5MNQ1Sc001009; Tue, 22 Jun 2004 16:26:05 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJQ21812; Tue, 22 Jun 2004 19:25:58 -0400 (EDT) Message-ID: <40D8C006.8070306@cisco.com> Date: Tue, 22 Jun 2004 19:25:58 -0400 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: Cullen Jennings Subject: Re: [Simple] Re: [Sipping] RE: text/T140 and audio/t140 was: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 References: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA12820 Cc: "'Paul E. Jones'" , "'Arnoud van Wijk'" , simple@ietf.org, Gregg Vanderheiden , "'Toip list'" , Gunnar Hellstrom , "'Mundra, Satish'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cullen Jennings wrote: > Dropped off sipping and avt and added simple mailing list... >=20 > I like this list but I think you have one other thing you want. You wan= t to > make a protocol that actually gets build and deployed. The narrower the > market is that is addressed by your solution or as it gets more complex= to > build, the less the odds are of it being build. IM is going to be build. > Session mode IM is highly likely to be build. >=20 > What would you need changed to the current requirements for session mod= e IM > in SIMPLE for it to meet all of your requirements? I believe there are = extra > requirements, I=B9m just trying to figure out what they are so perhaps = we can > see if they can be addressed in IM. Cullen, I am inclined to agree with you up to a point. It would be good if your=20 average IM client had this capability. But I don't think real time text=20 itself is a reasonable substitute for IM. I used to think real time text=20 was just a bad idea, but Gunnar now has me convinced that it has a role,=20 especially for the hard of hearing, but also for certain real time=20 situations like real time translation and captioning for video. For=20 other purposes I find the stuttering of character-at-a-time text really=20 annoying. (I usually don't want to watch while someone corrects their=20 spelling and changes their mind about what they want to say.) Since the text/t140 and audio/t140c is already defined, I see no reason=20 to worry about those requirements in something like MSRP. The more likely convergence to me is to work out the offer/answer usages=20 so that support for these can coexist in a single device. I see no=20 reason why my IM client can't support both. Hopefully I would normally=20 find myself using message-at-a-time communication, but if I found myself=20 talking to a RTT device the device and its UI should be able to=20 accomodate that. Paul > On 5/31/04 1:22 AM, "Gunnar Hellstrom" wr= ote: >=20 >=20 >>By this response, I include the SIPPING group in our discussion. >>So, introduction: We have created a new transport of real time text for >>character-by-character conversational use, called audio/t140c ( in the= drafts >>sofar we called it audio/t140, but in order to distinguish it more easi= ly in >>sdp and discussions we will now propose name change to audio/t140c ) >> >>The purpose of this format is to take text reliably between two PSTN tr= ansit >>gateways when the connection is used for IP transit of PSTN calls. It i= s said >>to be a benefit for the big gateways if they can use the same RTP strea= m for >>everything - voice, text, modem, fax, DTMF. >> >>So, this format is introduced in the revision of the rtp spec for text >>conversation rfc2793 that we are working on in avt. >>http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-04.txt >> >>The earlier transport text/t140 is still there, and is still compatible= with >>RFC2793, and is intended for both gateway and endpoint usage. >> >>Now it turns out that some designers may have had an intention to start= using >>the audio/t140c format in other applications than trunking PSTN calls, >>involving residential gateways and even SIP endpoint terminals. That ca= used a >>flame of discussion in avt, because that idea seems to threaten the who= le idea >>of orderly service provision in SIP networks. >> >>Such discussions are not right placed in avt. There we make the transpo= rt >>specifications and do not discuss deeply how these transports are going= to be >>included in network structures, or how they go together with ambitions = to >>offer ambitious new services with SIP. >> >>The right place for the discussion may be sipping or mmusic, and also i= n >>external groups picking up SIP and putting profiles and usage conventio= ns on >>it.=20 >> >>We have concluded that real time text is a medium in its own right, tha= t needs >>to be available simultaneously with voice in new networks. There is a l= ow >>functionality implementation of text in PSTN, but we do not want its >>limitations to influence the service provision in SIP. But we want to o= ffer >>gatewaying to it just as SIP voice telephony offers gatewaying to PSTN = voice >>telephony. >> >>The important functional goals we want to reach with text in SIP are at= least >>the following:=20 >> >> 1.Truly simultaneous text, voice and video. >> >> 2. Two way simultaneous transmission with a character-by-character fe= eling. >> >> 3. Internationally usable character set. >> >> 4. Capacity for transmission as fast as text can be produced by a typ= er and >>an automatic voice-to-text application - 30 characters per second. >> >> 5. Possibility to participate in managed conferences. >> >> 6. Good reliability and indication of rare loss to the user. >> >> 7. Good security >> >> 8. Declaration of the intention to use text in a session, and using t= hat >>knowledge in allocating resources for the call >> >> 9. Declaration of preference to use text as the main medium in a call= , and >>using that knowledge in routing calls. >> >> 10. Request to invoke text <-> voice transcoding services, and routin= g of >>the calls properly for that. >> >> 11. Offering text alternatives to Interactive Voice Response systems >> >> 12. Routing of emergency calls to agents used to handling text calls. >> >> 13. Implenmentation in most SIP devices with interoperability between= them. >> >> 14. Smooth ways to interoperate with conversational text in other net= works, >>e.g. PSTN. >> >>RFC3351 expresses some of these goals, and text is mentioned in many pl= aces in >>IETF specs. E.g. megaco requirements. rfc2793, rfc2793bis, sipping-toip= , >>sdp-new-16, avt-emergency, sipdev, callee-caps, transcoding. >> >>If text is not always declared as text in sdp, when SIP endpoints and >>residential gateways are involved in the sessions, we have little chanc= e to >>meet all the ambitions. That is the threat we see when designers coming= from >>the voice side start to think that they can use audio/t140c outside its >>original application in the big trunking gateways. >> >>The question to the sipping group who are new to this question is: Wher= e are >>there strong enough forces to encourage implementation of SIP in a way = so that >>all good features that are within reach from consistent application of = SIP are >>not spoiled by making shortcuts and imitating the limitations from the = voice >>dominated PSTN? >> >> >> >>Regards >> >>Gunnar=20 >> >>------------------------------------------- >>Gunnar Hellstr=F6m >>Omnitor AB >>Renathv=E4gen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>>-----Original Message----- >>>From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On Be= half Of >>>Gregg Vanderheiden >>>Sent: Monday, May 31, 2004 6:25 AM >>>To: 'Paul E. Jones'; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; 'Mundra, >>>Satish'; 'avt IETF'; 'Toip list' >>>Subject: RE: text/T140 and audio/t140 was: [avt] Comments/questions o= n >>>draft-ietf-avt-rfc2793bis-04 >>> >>> >>> >>> >>>Hmmm >>> >>> >>> >>>If we don't change from audio to T140-IP at all the fringes of the IP >>>network =AD then we risk all the problems inherent in TTY over IP and= make it >>>very hard to move off of TTY in the future since it will be embedded = in. >>> >>> >>> >>>Yes? >>> >>> >>> >>> >>>Gregg >>> >>>-- ------------------------------ >>>Gregg C Vanderheiden Ph.D. >>>Professor - Ind. Engr. & BioMed Engr. >>>Director - Trace R & D Center >>>University of Wisconsin-Madison >>> >>> >>> >>> >>> >>> >>> >>>From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On B= ehalf >>>Of Paul E. Jones >>>Sent: Wednesday, May 26, 2004 3:23 PM >>>To: Arnoud van Wijk; 'Gunnar Hellstrom'; 'Mundra, Satish'; 'avt IETF'= ; 'Toip >>>list' >>>Subject: Re: text/T140 and audio/t140 was: [avt] Comments/questions o= n >>>draft-ietf-avt-rfc2793bis-04 >>> >>> >>> >>> >>> >>>Arnoud, >>> >>> >>> >>> >>> >>> >>> >>>You are correct that not every residential GW will be used to call to= a PSTN >>>GW, but I will argue that most calls will be to PSTN GWs for a period= of >>>time. After that period of time, we will see a healthy mix of on-net= and >>>off-net calls, ultimately ending up with most calls being on-net. >>> >>> >>> >>> >>> >>> >>> >>>However, anytime that we connect a PSTN textphone to a residential ga= teway, >>>there is a very high degree of probability that the user will call an= other >>>user who is also using a PSTN textphone, either connected to the PSTN= or >>>hanging off of a residential gateway. So, the use of audio/t140 woul= d still >>>be quite useful and would probably be the likely mode for exchanging = text. >>> >>> >>> >>> >>> >>> >>> >>>I am not suggesting that the residential GWs not support text/t140-- = they >>>should for the benefit of interconnecting to pocket PCs or personal >>>computers running software that allows one to truly have simultaneous= voice, >>>video, and/or text. Likewise, we should see PSTN gateways support >>>text/t140, too. I just think that any device which interconnects wit= h a >>>legacy TTY will likely propose audio/t140 and I think that's OK. If = that >>>device calls a user on a PC, then the mode of communication should be >>>switched to text/t140-- and SIP offers that kind of negotiation. >>> >>> >>> >>> >>> >>> >>> >>>Paul >>> >>> >>> >>> >>> >>> >>>> >>>> >>>>----- Original Message ----- >>>> >>>> >>>> >>>>From: Arnoud van Wijk >>>> >>>> >>>> >>>>To: 'Gunnar Hellstrom' ; 'Mundr= a, >>>>Satish' ; 'Paul E. Jones' >>>> ; 'avt IETF' ;= 'Toip >>>>list' >>>> >>>> >>>> >>>>Sent: Wednesday, May 26, 2004 3:57 PM >>>> >>>> >>>> >>>>Subject: RE: text/T140 and audio/t140 was: [avt] Comments/questions = on >>>>draft-ietf-avt-rfc2793bis-04 >>>> >>>> >>>> >>>> >>>> >>>>Gunnar.. >>>> >>>>Amen! >>>> >>>> >>>> >>>>That is also my feeling. >>>> >>>>That is why I am trying to limit the uses for audio/t140. >>>> >>>>I still feel unhappy about audio/t140. >>>> >>>>And the answers from others that a residental gateway will use audio= /t140 >>>>makes me uneasy. >>>> >>>> >>>> >>>>The argument that such residental gateway will be used for mainly PS= TN >>>>calls=8A.I do not agree. It can also be through a VoIP server at you= r local >>>>network provider. And those can be interconnected with other local I= SPs and >>>>such. It is not default to PSTN. (right now in Holland, VoIP service= s are >>>>starting, with a residental gateway/modem and it is not aimed pstn o= nly). >>>> >>>>So lets keep the freedom of the IP telephony and focus on text/t140 = for >>>>residental gateways! >>>> >>>> >>>> >>>> >>>> >>>>Greetz >>>> >>>> >>>> >>>>Arnoud >>>> >>>> >>>> >>>> >>> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >=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-bounces@ietf.org Thu Jun 24 13:22:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01881 for ; Thu, 24 Jun 2004 13:22:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdXvl-0001LH-BS for simple-archive@ietf.org; Thu, 24 Jun 2004 13:22:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdXtv-0000TK-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 13:20:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdXsf-0007bl-00; Thu, 24 Jun 2004 13:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXIz-0001XI-8H; Thu, 24 Jun 2004 12:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2hu-0003J4-C4 for simple@megatron.ietf.org; Wed, 23 Jun 2004 04:02: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 EAA01712 for ; Wed, 23 Jun 2004 04:02:08 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2hs-00004a-33 for simple@ietf.org; Wed, 23 Jun 2004 04:02:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2KG-0003cR-00 for simple@ietf.org; Wed, 23 Jun 2004 03:37:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Bd1W5-00020P-00 for simple@ietf.org; Wed, 23 Jun 2004 02:45:53 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5N6jrN12006 for ; Wed, 23 Jun 2004 09:45:53 +0300 (EET DST) X-Scanned: Wed, 23 Jun 2004 09:45:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5N6jq5c007048 for ; Wed, 23 Jun 2004 09:45:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00JHicAI; Wed, 23 Jun 2004 09:45:51 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5N6joH15487 for ; Wed, 23 Jun 2004 09:45:50 +0300 (EET DST) Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Jun 2004 09:45:48 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Jun 2004 09:45:47 +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] New version of XCAP usage for manipulating presencedocument contents Date: Wed, 23 Jun 2004 09:45:48 +0300 Message-ID: Thread-Topic: [Simple] New version of XCAP usage for manipulating presencedocument contents Thread-Index: AcPvSAnlGDdWtkDYR5GSxd9IBCgMVgAoZA8QF+XUtEACWpsFIA== To: X-OriginalArrivalTime: 23 Jun 2004 06:45:47.0575 (UTC) FILETIME=[B71B9C70:01C458ED] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Mikko, Thanks for your comments! Please see replies to your comments inline. Mikko wrote: >=20 > Hi, >=20 > Below some comments to the draft. I will send all nits directly to = Markus. Almost all the nits will be considered in the new version. >=20 > Page 1, first paragraph: > Contains reference to RFC2026. Should be updated to RFC 3668 OK. >=20 > Section 1, introduction: > This section contains quite a lot requirement/use case text. This is > probably ok but I was wondering if this is really needed for WG draft? During the review of the previous version of this draft it was commented = that that draft should contain clear description of what are the use = cases for XCAP-based PIDF manipulation versus SIP PUBLISH. This is now = included, and I think it should be kept like that, so that this = consideration is not lost for the future readers who have not = participated in the discussion in the meetings or mailings lists. >=20 > Section 5, first parapraph: > " > The XML [5] format of the presence information (PIDF) is defined in > [3] and its extensions.=20 > " >=20 > Change to -> >=20 > " =20 > The XML [5] format of the presence information (PIDF) is defined in > PIDF [3]. PIDF also defines a mechanism how presence documents can be > extended. > "=20 The texts will be rephrased accordingly. >=20 > " > The PIDF defines the presence information to > consist of the root element 'presence' including 'tuples' which > contain a mandatory status element, a communication mean specific > presence attribute and other markups. > "=20 >=20 > Change to -> >=20 > "The PIDF defines the presence information to consist of the root > element 'presence'. The 'presence' element can contain=20 > 'tuple' elements > which contain a mandatory status element, a communication=20 > mean specific presence attribute and other markups.=20 > " OK. >=20 > Section 6: > This section sound very vague. Especially when document doesn't by > itself define any XML schema. It might be good to add some=20 > text explain what this computed data is. The current XCAP draft does not any more require the Computed Data = section to be=20 defined for an application usage so I propose the removal of the = section. >=20 > Section 7: > "There are no constraints on the document beyond those described in > the XML schemas and [3]. > " =09 > To what other schemas this section refers to than PIDF schema or what > are those other schemas? It refers to PIDF and its extensions. I'll rephrase the sentence. >=20 > Section 10: > " > The XML schema definition for the presence information can be found > from [3] and its extensions. > " >=20 > Change to -> >=20 > " > The XML schema definition for the presence information can be found > from PIDF [3]. PIDF presence document can also contain extensions like > RPID [ref]. > " The text will be rephrased accordingly. >=20 > Section 11, example: > For me this example is not totally clear in what it tries to > demonstrate. I think it tries to show an example what kind of presence > document can be published using XCAP. However, I could also=20 > ready it as > what PS should directly put into notifications which it sends to the > watchers. There could be more text saying that this is the presence > document provided from XCAP client to XCAP server. Ok - clarified. >=20 > Section 13.1, > " > Description: Pidf-manipulation application usage defines how XCAP is > used to manipulate the contents of presence documents in Session > Initiation Protocol (SIP) based presence systems. > " >=20 > Change to -> >=20 > " > Description: PIDF-manipulation application usage defines how XCAP is > used to manipulate the contents of PIDF based presence documents.=20 > " OK. >=20 > - Mikko -Eva _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 13:35:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03392 for ; Thu, 24 Jun 2004 13:35:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdY81-0005PW-LL for simple-archive@ietf.org; Thu, 24 Jun 2004 13:35:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdY50-0004Ie-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 13:32:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdY1W-00032g-00; Thu, 24 Jun 2004 13:28:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJD-0001bO-LJ; Thu, 24 Jun 2004 12:42:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2xY-0006LI-52 for simple@megatron.ietf.org; Wed, 23 Jun 2004 04:18: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 EAA04107 for ; Wed, 23 Jun 2004 04:18:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2xV-00032j-Sw for simple@ietf.org; Wed, 23 Jun 2004 04:18:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2jP-0000ZR-00 for simple@ietf.org; Wed, 23 Jun 2004 04:03:45 -0400 Received: from epact.se ([192.36.138.128]) by ietf-mx with esmtp (Exim 4.12) id 1Bd2M8-0004CO-00 for simple@ietf.org; Wed, 23 Jun 2004 03:39:40 -0400 Received: from krypton (krypton.epact.se [192.36.138.36]) by epact.se (8.12.11/8.12.10) with SMTP id i5N7dAgh016622 for ; Wed, 23 Jun 2004 09:39:10 +0200 From: "Henrik Leion" To: "Simple mailinglist" Subject: RE: [SIMPLE] Authorization of resource list back-end subscriptions Date: Wed, 23 Jun 2004 09:42:11 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40D8500F.7030408@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I give up. But I'm still convinced that SIP should have the option to have less security (security can be provided by other means) for the benefit of automatically authorize subscriptions from a dynamic group as a group instead of per user. Since the geopriv Common Policy only allows one uri element per rule, presentities will have to create one rule per subscriber. In the Porsche example, Bob and the other presentities would need to create 200 rules each, and add new as new members joined. By hand. Changing the From-header in the resource-list subscriptions seemed like a simple fix. One rule each. But if resource-lists will only be used for buddylists, I guess it's ok. /Henrik PS. About that car thief. He couldn't be avoided in the Porsche discussion group even if all subscriptions were labelled pres.example.com and the presentities authorized every single subscription by hand. The presentities would know the true identity of all members, but they still wouldn't know who took their cars. > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf > Of Paul Kyzivat > Sent: den 22 juni 2004 17:28 > To: Henrik Leion > Cc: Simple mailinglist > Subject: Re: [SIMPLE] Authorization of resource list back-end > subscriptions > > > Henrik, > > I think you are conflating unrelated concepts. The fact that I subscribe > to the porsche-owners list doesn't make me a porsche-owner. > > (In fact I may well aspire to be a porsche-owner by first being a > porsche-thief!) > > So it would be pretty dumb of you to grant me permission to subscribe to > your presence solely because I have subscribed to the porsche-owners list. > > What *might* make sense would be to find a way to share a single list > for two uses - as a buddy list for subscribing to presence, and as a > white list for *authorizing* subscription to presence. Then you might > choose both to subscribe to porsche-owners, and to use the > porsche-owners list as a white list for granting subscriptions to your > presence. (There are of course technical issues with accomplishing that.) > > Paul > > Henrik Leion wrote: > > Hmm, I feel we're talking and thinking about different things. > > All I'm saying is that it could be useful to see in what context someone > > wants my presence info, resource-lists can be used not only to make > > subscribing easier - it could help a presentity group subscriptions and > > automate authorization. > > Resource-lists can be so much more than just a server-sided > buddylist (where > > end-to-end authorization is undoubtedly best), think discussion-groups, > > conferences, games and future event packages. > > > > I'm not suggesting any changes in how subscribers are > authenticated, only > > that more information is given to the presentity to help him set up > > authorization rules (to automate more, not less). > > If the presentity would like to challenge a subscription > request, he would > > still identify the resource-list subscriber as usual. > > > > Consider this scenario: > > Bob (sip:Bob@bobs-company.com) is a member of these resource-lists: > > L1=Bobs-family@rls.example.com with 5 subscribers (Bob and > his family) > > L2=Porsche-Owners@rls.example.com with 200 subscribers > > > > Bob would like to publish much info to his family, but very > limited info to > > other Porsche-owners (say online status from his chat-client at > home and his > > cell phone's geoloc info when he's driving his Porsche). Bob accepts the > > risks with sending geoloc info to strangers, because he thinks > it's a nice > > way of meeting new friends and would like automate the authorization for > > members of that list. > > > > But when Bob gets a (back-end) subscription from > pres.example.com, challenge > > it and finds out it's Alice@another.domain.com, he still > doesn't know if she > > owns a Porsche, or if it's his cousin. > > If Bob instead gets a subscription from > porshe-owners@rls.example.com (again > > initialized by Alice), he may be content with that, not caring about the > > identity of that particular Porshe-owner, and set his policies to > > automatically authorize this subscription. > > > > The ideas on writing resourcelist-subscribers in presentity > watcher-info and > > allowing presentity to write authorization-rules for > resource-lists are a > > bit far out, I'll admit, but if the resource-lists are made > more visible, it > > would be possible for those software developers inclined. > > > > Although I never meant to suggest it, the possibility of having > the RLS to > > authenticate itself, instead of forwarding the authentication > request to the > > subscriber, is interesting (not annoying). The key is that if > the presentity > > does not know the subscriber, an authentication would not be very > > informative. But if the owner of the list instead says "I will > personally > > check that every subscriber is entitled to be on this list and kick out > > those that misbehave", and the subscribers trust him, they will have the > > possibility to automate authorization of strangers with more security. > > Check out the game Mogi > (http://www.thefeature.com/article?articleid=100501) > > that could use Sip this way. > > > > /Henrik > > > > > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: den 21 juni 2004 16:35 > >>To: Henrik Leion > >>Cc: Simple mailinglist > >>Subject: Re: [SIMPLE] Authorization of resource list back-end > >>subscriptions > >> > >> > >> > >> > >>Henrik Leion wrote: > >> > >>>Well, I just thought I'd toss in the idea. I believe that > >> > >>domains will be > >> > >>>small (office or home networks even) and that both inter-domain > >>>subscriptions and resource-list subscriptions will be very > common. I was > >>>thinking in these lines: > >>> > >>> - If the ideas with filters, authorization rules and partial > >> > >>presence will > >> > >>>be implemented, how many users can there be on one > >> > >>presence-server? Parsing > >> > >>>xml-docs is quite more time-consuming than just forwarding requests. > >> > >>I too am worried about this. Something that prevents a PS from having to > >>send a separate NOTIFY, with customized content, for every direct > >>subscriber, including thost that arrive indirectly via a list, would be > >>a good thing. But I'm not convinced you have found the right solution. > >> > >> > >>> - How large parts of the resource-lists will actually come > >> > >>from the same > >> > >>>presence-server and how much is back-end subscriptions? > >>> - If subscriptions are to be authorized using watcher-info > >> > >>notification and > >> > >>>XCAP, isn't it a bit boring that it just says > >> > >>"pres.example.com" instead of > >> > >>>at least saying what resource-list your presence is publicated > >> > >>on? Better > >> > >>>yet is that the winfo-file states the subscribers to the > resource-lists. > >> > >>Jonathan addressed this point. I'm with him on it. > >> > >> > >>>>- what kind of credential could the RLS have and provide when > >>>>subscribing that authenticates it as the resource-list? > >>> > >>>Well, actually I don't know. But what difference is there > between an RLS > >>>authenticating itself to a presentity using some > >> > >>"sip:pres.example.com" URI, > >> > >>>than should it use "sip:adam-friends@lists.example.com"? > >>>In either case the presentity have probably never heard of example.com > >>>before. > >> > >>If it were to authenticate as itself, then I agree its likely that > >>nobody would grant it authorization. Authenticating as the list itself > >>is indeed an improvement over that, but not a great one, because > >>authorizing it doesn't give me real control over who receives my > >>presence. More on that below. > >> > >> > >>>>- in case of private lists (e.g. I am the only one who subscribes to > >>>>*my* buddy list) having credentials for my buddy list is no > easier than > >>>>having credentials for me. > >>> > >>>Yes, I was thinking in the lines of public lists; intranet > >> > >>address-lists, > >> > >>>conferences, discussion groups etc. But I'm under the > >> > >>impression that the > >> > >>>RLS does not use the presentities credentials when creating a back-end > >>>subscription but instead acts on its own, "RLSes acts as a subscriber" > >>>[event-list draft]. > >> > >>Again, Jonathan spoke to this. Using the ultimate subscriber's > >>credentials is pretty important. > >> > >>*If* a list were *known* to be available to only a single subscriber (or > >>known list of subscribers I suppose), then authorizing based on > >>credentials for the list itself would perhaps be acceptable. (Though > >>annoying.) E.g. If I had a pending subscription from: > >> > >> sip:JohnSmith-buddylist@rls.example.com > >> > >>and sip:JohnSmith@example.com is indeed a buddy of mine, and I am > >>familiar with the example.com rls server and that buddy lists aren't > >>shared, then I might be inclined to grant the subscription. > >> > >> > >>>>- if the RLS server has lists L1 and L2 that both have a reference to > >>>>presentity P, then it still can't use a single subscription to P and > >>>>provide results to subscribers of both L1 and L2. > >>> > >>>Yes it could. > >>>P.winfo would contain L1 and L2 along with all other watchers that are > >>>interested in the presence of P. If P wants to check who > >> > >>actually subscribes > >> > >>>to L1 and L2, he would consult L1.winfo and L2.winfo. > >> > >>This is very different than the expected authorization model for > >>presence subscriptions. Normally, P will not care about authorized > >>watchers in P.winfo. Instead, all it will care about are those that are > >>'pending'. They are the watchers that want access to P's presence but > >>that have neither been granted nor denied it. User P then either grants > >>or denies them access, and never gives them another thought. > > > > > > Ah, yes. That what the draft says. Thanks > > > > > >>In the case of L1 and L2, P has to decide whether to grant access the > >>first time the server subscribes on behalf of each. User P can check who > >>is currently watching L1 or L2 at that time, but that will say nothing > >>about who may watch them at some other time. > >> > >> > >>>Another idea is to add a namespace to winfo for resourcelists, > >> > >>now P can see > >> > >>>anybody subscribing to him directly, instead of just knowing > >> > >>that an RLS is > >> > >>>subscribing. > >> > >>This doesn't solve the problem. As a notifier, I don't want to have to > >>recognize that a particular watcher is a list and then monitor the > >>subscribers of that list to decide moment-by-moment what I am > >>comfortable publishing to that set of watchers. And even if I was > >>willing to, there would be race conditions so that what I publish could > >>go to someone I didn't expect > >> > >>For such a system to work at all, it would need to be based on who is > >>*authorized* to watch the list, not who is currently watching it. And > >>even then, it would be a bad system. The notifier would have to tailor > >>the content published to the intersection of what it is willing to make > >>available to any of the potential subscribers to the list. That isn't > >>going to be very appealing to subscribers that would otherwise be able > >>to see more. > >> > >> > >>>>Well, maybe it *could* but that sounds really cumbersome, > expensive, and > >>>>not especially reliable. Can I ever safely decide what to > disclose based > >>>>on who I think is currently subscribing to that list, rather than who > >>>>potentially *could* subscribe to it? > >>> > >>>But that's the whole idea behind presence authorization using > >> > >>winfo-lists, > >> > >>>isn't it? > >> > >>No. See above. > >> > >> > That you can trust the presence server that it only sends your > >> > >>>presence information to those watchers that are marked "active" in your > >>>winfo-file. When new subscriptions come, the presence server > will either > >>>allow or disallow it judging from authorization rules, or > >> > >>otherwise set the > >> > >>>subscription-state to "pending" and let the presentity decide. > >>>If you don't trust that the server will act this way in the > future, send > >>>less information. > >> > >>This is way to dynamic for making policy decisions. > >> > >> > >>>Those present on a resource-list should be allowed to create > >> > >>resource-list > >> > >>>authorization rules appliable to their own presence. > >>>L1 has two subscribers S1a and S1b. P may be authorized to > >> > >>create a rule in > >> > >>>L1.auth that always transforms his presence to appear offline > >> > >>to S1b, whilst > >> > >>>S1a will get P's true presence. > >>>The authorization rules of a resource list should belong to the > >> > >>people on > >> > >>>it, at least in public applications, such as conference lists. But in a > >>>black-list or buddylist application the idea is probably quite stupid. > >> > >>Well, that would solve some of the problems. But it presents serious > >>issues of trust. Why should I believe that I can trust the RLS managing > >>L1 to administer my policies? > >> > >>And mechanistically, I don't think I would want to deal with that kind > >>of authorization manually. > >> > >>It sounds to me like that is a potential optimization that could be > >>carried out among a set of mutually cooperating servers that have > >>suitable mutual trust arrangements. In that case the user should not > >>have to do anything special - the appropriate authorization rules would > >>be shared among the servers. > >> > >> 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 13:56:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05280 for ; Thu, 24 Jun 2004 13:56:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYSB-000356-Uf for simple-archive@ietf.org; Thu, 24 Jun 2004 13:56:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYFm-0000mm-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 13:43:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYE8-0007fS-02; Thu, 24 Jun 2004 13:41:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYE3-0008Qw-IP; Thu, 24 Jun 2004 13:41:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXKV-00024J-Nt; Thu, 24 Jun 2004 12:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd8yi-0005Eh-24 for simple@megatron.ietf.org; Wed, 23 Jun 2004 10:43: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 IAA28459 for ; Wed, 23 Jun 2004 08:59:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd7La-0002GC-Mr for simple@ietf.org; Wed, 23 Jun 2004 08:59:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd7Kb-0001pp-00 for simple@ietf.org; Wed, 23 Jun 2004 08:58:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Bd7Jh-000149-00 for simple@ietf.org; Wed, 23 Jun 2004 08:57:29 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 23 Jun 2004 05:59:33 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5NCul4N025480; Wed, 23 Jun 2004 05:56:48 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJQ46746; Wed, 23 Jun 2004 08:56:45 -0400 (EDT) Message-ID: <40D97E0D.1030906@cisco.com> Date: Wed, 23 Jun 2004 08:56:45 -0400 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: Gunnar Hellstrom Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: [avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "'Paul E. Jones'" , "'Arnoud van Wijk'" , simple@ietf.org, Gregg Vanderheiden , "'Toip list'" , "'Mundra, Satish'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > Cullen and all, > Thanks for taking the discussion on real time text conversation into SIMPLE. > > So far, I have regarded SIMPLE to be a messaging protocol, that handles a medium level of > timing requirements with complete messages in video, text, voice and images. And Server > based? > Right? > It definitely serves its purpose very well, and I really wish it will create some openness > in the messaging world. > > What we have in avt and sipping in the text/t140 (rfc2793 and RFC2793bis ) is a real time > character-by-character text protocol, ready to flow in parallell to voice and video in a > regular Multimedia IP call. Based on RTP, but with good reliability. > It has been proven that it is needed as a companion to the voice and video paths of phone > calls. > > Of course we want to see it more implemented to give full benefit to users who need or > want text in the calls. It is so easy to implement. It uses all the same mechanisms as the > other real time media in the call. > > I see multimedia divided in at least three time relations. > > 1. Real time conversation. With video, text and voice flowing in real time straight > between two terminals. > > 2. Messaging. Compose a message and transmit. Usually via a server. SIMPLE, SMS. > > 3. Stored and editied multimedia for retrieval or broadcasting. > > Cullen, you indicate that you think it would be easier to get to widespread implementation > by making SIMPLE handle character-by-character transmission, than by making the videophone > producers add the real time text RTP? Why, Seems to me the question is what devices (hard or soft) have a suitable UI for dealing with text? - A simple audio phone doesn't. - A "hard" video phone with just a number pad for input isn't well suited for text input. It could potentially do text output, but that may not fit well - especially not if a full history is to be kept. - A soft video phone, on a computer with a keyboard, has less of the limitations of a hard video phone. But the closer it attempts to emulate a hard video phone, or an audio phone, the less suited it will be. - OTOH, an IM client has all the mechanics for text entry and display, including the full conversation log. So it has most of the UI needed to support real time text. I don't have experience with a real time text application, but I suspect that it may prefer a UI somewhat different than an IM client UI, so perhaps there is a market for a custom UI for those that use this medium a lot. But I also suspect that the IM client UI can be easily adapted so that it is reasonably suitable for real time text - good for those who use it occasionally. > and would it not be a complicated mixed > protocol for a call, with straight SIP call establishment for the video and voice media, > and then involving SIMPLE and its server for the text part??????????? This should be no more difficult than dealing with an audio/video call - that involves establishing separate audio and video media streams. Its just a matter of establishing the third stream (or the 2nd stream if text is used *instead* of voice.) It has certainly been my goal all along in the MSRP work to ensure that IM is indeed just another media stream. > Is it not more straightforward to just add another RTP medium to the call? It is already > proven, implementations exist, the medium flows wherever the other media flows. Its just another medium in any case. Perhaps text over RTP is marginally simpler just because establishing RTP based media streams is more familiar than TCP based ones. But TCP has been chosen for MSRP because it is better suited to the message oriented protocol that doesn't have tight real time constraints. The only real new complexity here (and it isn't *that* new) is working out how to handle offer/answer among endpoints that can do both MSRP and text/t140 but consider them mutually exclusive. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 14:08:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07059 for ; Thu, 24 Jun 2004 14:08:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYeK-000505-8p for simple-archive@ietf.org; Thu, 24 Jun 2004 14:08:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYPA-0002Ma-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 13:52:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYEv-0000Dh-00; Thu, 24 Jun 2004 13:42:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdY27-0007Tb-FC; Thu, 24 Jun 2004 13:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJI-0001cu-CK; Thu, 24 Jun 2004 12:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd30W-0006wp-HQ for simple@megatron.ietf.org; Wed, 23 Jun 2004 04:21: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 EAA04756 for ; Wed, 23 Jun 2004 04:21:22 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd30U-000440-57 for simple@ietf.org; Wed, 23 Jun 2004 04:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2mm-0001Mq-00 for simple@ietf.org; Wed, 23 Jun 2004 04:07:13 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Bd2Qn-00059w-00 for simple@ietf.org; Wed, 23 Jun 2004 03:44:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5N7iIN08125; Wed, 23 Jun 2004 10:44:18 +0300 (EET DST) X-Scanned: Wed, 23 Jun 2004 10:44:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5N7i7oe015414; Wed, 23 Jun 2004 10:44:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00RHrT8V; Wed, 23 Jun 2004 10:44:07 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5N7i5H06769; Wed, 23 Jun 2004 10:44:05 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Jun 2004 10:43:58 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RPID: what does tuple-type really mean? Date: Wed, 23 Jun 2004 10:43:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D3B@esebe004.ntc.nokia.com> Thread-Topic: [Simple] RPID: what does tuple-type really mean? Thread-Index: AcRXdpHsxZF6PpZkQguatxdGA/IDdgABMUMw To: X-OriginalArrivalTime: 23 Jun 2004 07:43:58.0054 (UTC) FILETIME=[D7987060:01C458F5] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable =20 > >>From partial notification point of view it should be enough > if these > >>new > > elements would have similar ID attribute as tuples > currently have and > > that they would share the same ID space. If there can be multiple > > occurrences of these new 'wrapper types' having similar ID=20 > as in tuple > > makes would be beneficial whether you use partial notifications or > > not. >=20 > I think it makes sense to use the same id attribute and space. My > question is, if you did this, would a client that implemented the=20 > partial notification spec, but didnt know about a new=20 > element,=20 > peer to , properly construct a PIDF document when sent partial=20 > notifications that indicate changes or removal of elements? Well, that might work but in order to be on a safe side it would be better if clients would explicitly know about elements. If attributes would have namespace this should not be a problem but as there is no way to know if id attribute really is the same id attribute there might be some nasty conflicts. - Mikko=20 > -Jonathan R. >=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 14:30:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10151 for ; Thu, 24 Jun 2004 14:30:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYzJ-00020S-Hz for simple-archive@ietf.org; Thu, 24 Jun 2004 14:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYnn-00076z-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 14:18:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYZN-00041b-00; Thu, 24 Jun 2004 14:03:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYRO-0000wf-6t; Thu, 24 Jun 2004 13:55:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXMY-0002Om-Hu; Thu, 24 Jun 2004 12:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdC1U-0001s2-GR for simple@megatron.ietf.org; Wed, 23 Jun 2004 13:59: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 NAA22255 for ; Wed, 23 Jun 2004 13:58:58 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdC1T-0006mf-1g for simple@ietf.org; Wed, 23 Jun 2004 13:58:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdB5p-0005y9-00 for simple@ietf.org; Wed, 23 Jun 2004 12:59:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Bd9oD-0004gM-00 for simple@ietf.org; Wed, 23 Jun 2004 11:37:09 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5NFawN07361; Wed, 23 Jun 2004 18:36:58 +0300 (EET DST) X-Scanned: Wed, 23 Jun 2004 18:36:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5NFasc6005065; Wed, 23 Jun 2004 18:36:54 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00vv3mrJ; Wed, 23 Jun 2004 18:36:54 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5NFarH25871; Wed, 23 Jun 2004 18:36:53 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Jun 2004 18:36:53 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] RPID: what does tuple-type really mean? Date: Wed, 23 Jun 2004 18:36:52 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D43@esebe004.ntc.nokia.com> Thread-Topic: [Simple] RPID: what does tuple-type really mean? Thread-Index: AcRZM0NYn7fMz9iNSLaZUBhBZZqoPgAA7xAA To: X-OriginalArrivalTime: 23 Jun 2004 15:36:53.0568 (UTC) FILETIME=[E8B84400:01C45937] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > >>I think it makes sense to use the same id attribute and space. My=20 > >>question is, if you did this, would a client that implemented the=20 > >>partial notification spec, but didnt know about a new =20 > >>element, peer to , properly construct a PIDF=20 > document when sent=20 > >>partial notifications that indicate changes or removal of =20 > >>elements? > >=20 > >=20 > > Well, that might work but in order to be on a safe side it would be=20 > > better if clients would explicitly know about elements. If=20 > > attributes would have namespace this should not be a problem but as=20 > > there is no way to know if id attribute really is the same id=20 > > attribute there might be some nasty conflicts. >=20 > Sorry, I don't quite follow here. What does attribute=20 > namespaces have to=20 > do with it? Ok, let's try to sort this out. As far as I know attributes in XML don't belong to any namespace. This means that if we want to have id attribute in we need to separately define it within . This id also has (in XML) nothing to do with id. Now, if somebody would define a new element which would also have id attribute (with different semantics) client would have no way to distinguish this from id or from id. This more or less means that client must be explicitly aware of element. - Mikko > -Jonathan R. >=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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 14:30:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10282 for ; Thu, 24 Jun 2004 14:30:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYze-00024O-Bu for simple-archive@ietf.org; Thu, 24 Jun 2004 14:30:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYoB-0007C0-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 14:18:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYZb-00041b-00; Thu, 24 Jun 2004 14:03:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYQr-0000to-Td; Thu, 24 Jun 2004 13:54:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXLv-0002M5-GY; Thu, 24 Jun 2004 12:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdBlB-0005mG-SQ for simple@megatron.ietf.org; Wed, 23 Jun 2004 13:42: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 NAA18067 for ; Wed, 23 Jun 2004 13:42:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdBlA-0003VC-He for simple@ietf.org; Wed, 23 Jun 2004 13:42:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdAT5-0001gk-00 for simple@ietf.org; Wed, 23 Jun 2004 12:19:24 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd9Vr-0001ma-00 for simple@ietf.org; Wed, 23 Jun 2004 11:18:11 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5NFGkbo029166; Wed, 23 Jun 2004 11:16:48 -0400 (EDT) Message-ID: <40D99EC7.9020501@dynamicsoft.com> Date: Wed, 23 Jun 2004 11:16:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices References: <2038BCC78B1AD641891A0D1AE133DBB701797C97@esebe019.ntc.nokia.com> <40D2E2C0.7040401@dynamicsoft.com> <40D2F8ED.7060005@cisco.com> <40D41DBF.10209@dynamicsoft.com> <40D648EA.6080700@cisco.com> <1087828039.2162.2.camel@localhost.localdomain> <40D7344B.8070905@cisco.com> <1087847596.2941.20.camel@localhost.localdomain> <40D75FC3.4070200@cisco.com> <40D867E4.3030500@dynamicsoft.com> <40D875E1.3030300@cisco.com> In-Reply-To: <40D875E1.3030300@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Hisham Khartabil , Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Jonathan, > > I'm not understanding you. I guess you are just saying that URI > cannonicalization is *defined* as part of registration. All I was saying is that we have already defined URI canonicalization as part of registration, and that I was suggesting that a client SHOULD follow those procedures, along with a tolower() on the domain, when it constructs a new entry to be added to a list stored on the server. > > And then you are suggesting it *should* be used in xcap list manip??? Yes. > > Maybe SHOULD is ok. But then the SHOULD will have to be ignored if the > canonicalization removes parameters that are important (such as > user=phone.) I suppose, see below. > > (The cannonicalization could be a problem with REGISTER, but probably > not in practice, since it only applies to AORs, and its hard to think of > a case where two AORs only differ by a URI parameter.) Right, and my assumption was that the URI that goes into each entry in the list would also be an aor, and thus I'm not sure when the inclusion of a user=phone would be important to the server processing the request for that AOR. -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-bounces@ietf.org Thu Jun 24 14:30:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10347 for ; Thu, 24 Jun 2004 14:30:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYzr-00027F-Tt for simple-archive@ietf.org; Thu, 24 Jun 2004 14:30:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYoT-0007Fc-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 14:19:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYZj-00041b-00; Thu, 24 Jun 2004 14:03:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYPv-0000os-J7; Thu, 24 Jun 2004 13:53:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXLR-0002IK-1h; Thu, 24 Jun 2004 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdBPe-0001EF-2j for simple@megatron.ietf.org; Wed, 23 Jun 2004 13:19: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 NAA14535 for ; Wed, 23 Jun 2004 13:19:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdBPc-00009Y-QY for simple@ietf.org; Wed, 23 Jun 2004 13:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd9xg-0005s0-00 for simple@ietf.org; Wed, 23 Jun 2004 11:46:57 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd9Gh-0007ME-00 for simple@ietf.org; Wed, 23 Jun 2004 11:02:31 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5NF1mbo029150; Wed, 23 Jun 2004 11:02:02 -0400 (EDT) Message-ID: <40D99B45.2070003@dynamicsoft.com> Date: Wed, 23 Jun 2004 11:01:25 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D3B@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D3B@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. mikko.lonnfors@nokia.com wrote: >>I think it makes sense to use the same id attribute and space. My >>question is, if you did this, would a client that implemented the >>partial notification spec, but didnt know about a new >> element, >>peer to , properly construct a PIDF document when sent partial >>notifications that indicate changes or removal of elements? > > > Well, that might work but in order to be on a safe side it would be > better if clients would explicitly know about elements. If > attributes would have namespace this should not be a problem but as > there is no way to know if id attribute really is the same id attribute > there might be some nasty conflicts. Sorry, I don't quite follow here. What does attribute namespaces have to do with it? -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-bounces@ietf.org Thu Jun 24 14:49:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12031 for ; Thu, 24 Jun 2004 14:49:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdZHu-0005kJ-ML for simple-archive@ietf.org; Thu, 24 Jun 2004 14:49:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdZ0f-0002Fp-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 14:31:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYoh-0007Fq-01; Thu, 24 Jun 2004 14:19:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYn2-0002HL-S2; Thu, 24 Jun 2004 14:17:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXO1-00031V-9S; Thu, 24 Jun 2004 12:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdDte-0007ps-Tn for simple@megatron.ietf.org; Wed, 23 Jun 2004 15:59: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 PAA11688 for ; Wed, 23 Jun 2004 15:59:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdDtd-0006Ci-DQ for simple@ietf.org; Wed, 23 Jun 2004 15:59:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdDsi-0005qD-00 for simple@ietf.org; Wed, 23 Jun 2004 15:58:04 -0400 Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 1BdDs0-0005Py-00 for simple@ietf.org; Wed, 23 Jun 2004 15:57:20 -0400 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040623195650.RBJE24679.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net> for ; Wed, 23 Jun 2004 14:56:50 -0500 Received: from opwvmdasari1 ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040623195650.RXLR1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> for ; Wed, 23 Jun 2004 14:56:50 -0500 From: "Murty Dasari" To: Date: Wed, 23 Jun 2004 12:56:48 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRZXDhFqrAXDGTSTECRRfvz1Krj+g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-Id: <20040623195650.RXLR1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> Subject: [Simple] MSRP: Lack of version in the protocol X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0388505018==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --===============0388505018== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C45921.8C3BAB10" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C45921.8C3BAB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I've a question about MSRP protocol (based on draft-ietf-simple-message-sessions-06.txt) Currently MSRP messages do not contain any version information. Wouldn't it be helpful to have major and minor version numbers similar to HTTP? Is there some other way to support multiple protocol revisions and future MSRP methods? Appreciate any comments. thanks, - Murty ------=_NextPart_000_0004_01C45921.8C3BAB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve a question about MSRP protocol (based on = draft-ietf-simple-message-sessions-06.txt)  

 

Currently MSRP messages do not contain any version information. Wouldn’t it be helpful to have major and minor = version numbers similar to HTTP?

Is there some other way to support multiple protocol revisions and future MSRP methods?

 

Appreciate any comments.

 

thanks,

- Murty

------=_NextPart_000_0004_01C45921.8C3BAB10-- --===============0388505018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0388505018==-- From simple-bounces@ietf.org Thu Jun 24 14:49:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12085 for ; Thu, 24 Jun 2004 14:49:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdZI6-0005mS-Dk for simple-archive@ietf.org; Thu, 24 Jun 2004 14:49:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdZ0p-0002Hg-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 14:31:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYoi-0007Fq-05; Thu, 24 Jun 2004 14:19:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYmS-0002Gg-7G; Thu, 24 Jun 2004 14:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXO0-00031Q-Mk; Thu, 24 Jun 2004 12:47:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdDiq-0006IW-I6 for simple@megatron.ietf.org; Wed, 23 Jun 2004 15:47: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 PAA10709 for ; Wed, 23 Jun 2004 15:47:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdDip-0001q1-1U for simple@ietf.org; Wed, 23 Jun 2004 15:47:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdDhq-0001Rv-00 for simple@ietf.org; Wed, 23 Jun 2004 15:46:51 -0400 Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 1BdDh2-0000hs-00 for simple@ietf.org; Wed, 23 Jun 2004 15:46:00 -0400 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040623194530.QWTS24679.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net> for ; Wed, 23 Jun 2004 14:45:30 -0500 Received: from opwvmdasari1 ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040623194530.RUYQ1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> for ; Wed, 23 Jun 2004 14:45:30 -0500 From: "Murty Dasari" To: Date: Wed, 23 Jun 2004 12:45:29 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRZWqMWUclTlU/ZTb+7MNA1UqLbrQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-Id: <20040623194530.RUYQ1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> Subject: [Simple] MSRP Boundary header X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100529643==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --===============2100529643== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C4591F.F750EA70" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4591F.F750EA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I've a question about MSRP (based on draft-ietf-simple-message-sessions-06.txt) "Closing" field. What is the need for a "Closing" field? Can't we use "Content-Length" similar to HTTP for determining the message body length? If this is there for "Continuation-Flag" then probably we can have another header that indicates continuation status. Though it might not be lot of work to determine the "closing" tag, it might be easy for the relays and clients to retrieve the message body based on content-length header; further, we don't have to add restrictions on presence of "boundary" in the message body in this case. This question might have brought-up/answered earlier, but I couldn't find out from the archives. Appreciate any comments. Thanks for your time. - Murty ------=_NextPart_000_0000_01C4591F.F750EA70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’ve a question about MSRP (based on draft-ietf-simple-message-sessions-06.txt) “Closing” = field.

 

What is the need for a “Closing” = field?

 

Can’t we use “Content-Length” = similar to HTTP for determining the message body length? If this is there for = “Continuation-Flag” then probably we can have another header that indicates continuation = status. Though it might not be lot of work to determine the = “closing” tag, it might be easy for the relays and clients to retrieve the message body = based on content-length header; further, we don’t have to add = restrictions on presence of “boundary” in the message body in this = case.

 

This question might have brought-up/answered earlier, = but I couldn’t find out from the archives. Appreciate any = comments.

 

Thanks for your time.

- Murty

 

------=_NextPart_000_0000_01C4591F.F750EA70-- --===============2100529643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2100529643==-- From simple-bounces@ietf.org Thu Jun 24 15:04:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13603 for ; Thu, 24 Jun 2004 15:04:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdZVx-0000Rm-16 for simple-archive@ietf.org; Thu, 24 Jun 2004 15:04:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdZ8r-0003eP-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 14:40:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdYs4-00000N-00; Thu, 24 Jun 2004 14:22:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXOI-000376-5h; Thu, 24 Jun 2004 12:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdEZH-0008Fk-CU for simple@megatron.ietf.org; Wed, 23 Jun 2004 16:42: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 QAA15715 for ; Wed, 23 Jun 2004 16:42:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdEZF-0007gO-IR for simple@ietf.org; Wed, 23 Jun 2004 16:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdEYQ-0007JJ-00 for simple@ietf.org; Wed, 23 Jun 2004 16:41:10 -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 1BdEXc-0006vb-00 for simple@ietf.org; Wed, 23 Jun 2004 16:40:21 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i5NKcxhZ009455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jun 2004 15:39:01 -0500 Message-ID: <40D9EA62.2010906@softarmor.com> Date: Wed, 23 Jun 2004 15:38:58 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: [avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: In-Reply-To: X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > Cullen and all, > Thanks for taking the discussion on real time text conversation into SIMPLE. > > So far, I have regarded SIMPLE to be a messaging protocol, that handles a medium level of > timing requirements with complete messages in video, text, voice and images. And Server > based? > Right? Nope. SIMPLE is just a working group. There is no SIMPLE protcol. The working group is dealing with presence and messaging using SIP, defining messaging transport protocols like MSRP, and defining presence data manipulation protocols like XCAP. MSRP, as defined, is much as you have described above. SIP MESSAGE requests can also be used to do less conversational messaging. Would your requirements be meetable with a real-time mode for MSRP? Something to think about. . . . > Cullen, you indicate that you think it would be easier to get to widespread implementation > by making SIMPLE handle character-by-character transmission, than by making the videophone > producers add the real time text RTP? Why, and would it not be a complicated mixed > protocol for a call, with straight SIP call establishment for the video and voice media, > and then involving SIMPLE and its server for the text part??????????? MSRP is already negotiated using SIP. MSRP can be set up in conjunction with RTP by a SIP negotiation. MSRP can be made to work with or without relays. MSRP is reliable. MSRP can be securely negotiated through an MSRP-aware firewall. But right now, it buffers at the message level rather than the character level and doesn't deal with intercharacter timing, so all it misses is your rough-approximation-of-real-time requirement. > Is it not more straightforward to just add another RTP medium to the call? It is already > proven, implementations exist, the medium flows wherever the other media flows. Sure, it's straightforward. But I still feel that RTP is just not suitable for text, no matter HOW much forward error correction you apply. It doesn't detect and react to congestion. It gets delivered out-of-order. It gets discarded by busy routers, and not resent. You might do a lightweight UDP protocol with in-order delivery and incremental acknowledgement, but that wouldn't be RTP. It would be more like ntalk, which has been around for a while. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 16:35:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27901 for ; Thu, 24 Jun 2004 16:35:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdawX-00020i-VO for simple-archive@ietf.org; Thu, 24 Jun 2004 16:35:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdaKc-0002hQ-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 15:56:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdZn4-0003yr-00; Thu, 24 Jun 2004 15:21:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPS-0003SL-Kx; Thu, 24 Jun 2004 12:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdEjE-0001l1-Tr; Wed, 23 Jun 2004 16:52:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16735; Wed, 23 Jun 2004 16:52:18 -0400 (EDT) Message-Id: <200406232052.QAA16735@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Jun 2004 16:52:18 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-filter-funct-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Functional Description of Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-event-filter-funct-01.txt Pages : 30 Date : 2004-6-23 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-event-filter-funct-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-event-filter-funct-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: <2004-6-23171230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-filter-funct-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-filter-funct-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-23171230.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Jun 24 16:52:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05847 for ; Thu, 24 Jun 2004 16:52:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdbD5-0004ke-La for simple-archive@ietf.org; Thu, 24 Jun 2004 16:52:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdaVw-0004fz-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:08:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdZwY-0005fm-00; Thu, 24 Jun 2004 15:31:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPg-0003VV-EO; Thu, 24 Jun 2004 12:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdF40-0004ru-Kp for simple@megatron.ietf.org; Wed, 23 Jun 2004 17:13: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 RAA18722 for ; Wed, 23 Jun 2004 17:13:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdF3y-0004JH-K0 for simple@ietf.org; Wed, 23 Jun 2004 17:13:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdF2o-0003pg-00 for simple@ietf.org; Wed, 23 Jun 2004 17:12:35 -0400 Received: from av1-1-sn1.fre.skanova.net ([81.228.11.107]) by ietf-mx with esmtp (Exim 4.12) id 1BdF1w-0003OZ-00 for simple@ietf.org; Wed, 23 Jun 2004 17:11:40 -0400 Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 1B23037F7D; Wed, 23 Jun 2004 23:11:09 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 0BFA137E91; Wed, 23 Jun 2004 23:11:09 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id D161B37E45; Wed, 23 Jun 2004 23:11:08 +0200 (CEST) From: "Gunnar Hellstrom" To: "Dean Willis" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: [avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Wed, 23 Jun 2004 23:11:11 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40D9EA62.2010906@softarmor.com> Importance: Normal Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dean, Thanks for explanations. You say: "Sure, it's straightforward. But I still feel that RTP is just not suitable for text, no matter HOW much forward error correction you apply. It doesn't detect and react to congestion. It gets delivered out-of-order. It gets discarded by busy routers, and not resent. You might do a lightweight UDP protocol with in-order delivery and incremental acknowledgement, but that wouldn't be RTP. It would be more like ntalk, which has been around for a while." Our experience with a couple of generations of RFC2198 redundancy is very good. Remember, if you have 10% loss, already by one repetition you are down to 0.1*0.1 = 1% loss. If you repeat once more, you get 0.01*0.1 = 0.1 % loss. That is far better than any typist already with only two generations. Takes very little space. I just started up an installation where we happened to get 40% loss because of some network configuration problems. Video was lousy, audio sounded pling scratch, but text got through beautifully without problems. Bringing packets back to order in case of misordering is a simple procedure normal for RTP. One good thing is that the medium gets through where the other media gets through. No extra protocol compatibility needed in the routers, just plain SIP RTP compatibility. Also the multiparty meeting arrangements gets so familiar because they are similar to video. SIMPLE has no ambitions to carry real time audio and video. So, why real time text when there is already one acknowledged way to transmit text that has been standard since 2000, and is entered in a number of higher level documents? Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com] >Sent: Wednesday, June 23, 2004 10:39 PM >To: Gunnar Hellstrom >Cc: Cullen Jennings; 'Toip list'; simple@ietf.org >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: >[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > >Gunnar Hellstrom wrote: >> Cullen and all, >> Thanks for taking the discussion on real time text conversation into SIMPLE. >> >> So far, I have regarded SIMPLE to be a messaging protocol, that handles a >medium level of >> timing requirements with complete messages in video, text, voice and images. And Server >> based? >> Right? > >Nope. > >SIMPLE is just a working group. There is no SIMPLE protcol. The working >group is dealing with presence and messaging using SIP, defining >messaging transport protocols like MSRP, and defining presence data >manipulation protocols like XCAP. > >MSRP, as defined, is much as you have described above. SIP MESSAGE >requests can also be used to do less conversational messaging. > >Would your requirements be meetable with a real-time mode for MSRP? >Something to think about. > >. . . > >> Cullen, you indicate that you think it would be easier to get to widespread >implementation >> by making SIMPLE handle character-by-character transmission, than by making >the videophone >> producers add the real time text RTP? Why, and would it not be a complicated mixed >> protocol for a call, with straight SIP call establishment for the video and >voice media, >> and then involving SIMPLE and its server for the text part??????????? > >MSRP is already negotiated using SIP. MSRP can be set up in conjunction >with RTP by a SIP negotiation. MSRP can be made to work with or without >relays. MSRP is reliable. MSRP can be securely negotiated through an >MSRP-aware firewall. But right now, it buffers at the message level >rather than the character level and doesn't deal with intercharacter >timing, so all it misses is your rough-approximation-of-real-time >requirement. > >> Is it not more straightforward to just add another RTP medium to the call? It >is already >> proven, implementations exist, the medium flows wherever the other media flows. > >Sure, it's straightforward. But I still feel that RTP is just not >suitable for text, no matter HOW much forward error correction you >apply. It doesn't detect and react to congestion. It gets delivered >out-of-order. It gets discarded by busy routers, and not resent. You >might do a lightweight UDP protocol with in-order delivery and >incremental acknowledgement, but that wouldn't be RTP. It would be more >like ntalk, which has been around for a while. > >-- >Dean > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 17:08:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11217 for ; Thu, 24 Jun 2004 17:08:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdbSm-0000E8-1k for simple-archive@ietf.org; Thu, 24 Jun 2004 17:08:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdapL-0000jN-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:28:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaDm-0001TE-01; Thu, 24 Jun 2004 15:49:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bda4U-0007OB-IL; Thu, 24 Jun 2004 15:39:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPv-0003dY-DH; Thu, 24 Jun 2004 12:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdGSg-0001KP-0H for simple@megatron.ietf.org; Wed, 23 Jun 2004 18: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 SAA25260 for ; Wed, 23 Jun 2004 18:43:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdGSe-0007Xg-51 for simple@ietf.org; Wed, 23 Jun 2004 18:43:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdGRU-0007Ar-00 for simple@ietf.org; Wed, 23 Jun 2004 18:42:09 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1BdGQy-0006na-00 for simple@ietf.org; Wed, 23 Jun 2004 18:41:36 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i5NMf1ih017631 for ; Wed, 23 Jun 2004 17:41:01 -0500 (CDT) Message-ID: <40DA06FC.F14CCE99@alcatel.com> Date: Wed, 23 Jun 2004 17:41:00 -0500 From: Jing Qian Organization: Alcatel X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701797B9F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] How to get SIP phone presence info X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, I am working on the Presence Server to get the presence status of a specific user's SIP phone - on the call , not on the call - a user based SIP phone status. Currently, there is no standard SIP server or SIP PBX available. Would anybody give me an idea how can the presence status of a SIP phone be published to a Presence Server by a SIP server/PBX or other service? Any idea will be appreciated. Thanks in advance. Jing _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 17:27:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13298 for ; Thu, 24 Jun 2004 17:27:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdbkS-0003GE-P2 for simple-archive@ietf.org; Thu, 24 Jun 2004 17:27:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdb56-0003T2-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:44:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaTY-0004Gc-00; Thu, 24 Jun 2004 16:05:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdaQp-0000ij-ON; Thu, 24 Jun 2004 16:02:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXSD-0004Oz-0c; Thu, 24 Jun 2004 12:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdQma-0000xq-Do for simple@megatron.ietf.org; Thu, 24 Jun 2004 05:44: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 FAA19745 for ; Thu, 24 Jun 2004 05:44:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdQmX-0007Rt-LM for simple@ietf.org; Thu, 24 Jun 2004 05:44:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdQlk-00075p-00 for simple@ietf.org; Thu, 24 Jun 2004 05:43:44 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdQlB-0006iQ-00 for simple@ietf.org; Thu, 24 Jun 2004 05:43:09 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5O9gobo029583; Thu, 24 Jun 2004 05:42:51 -0400 (EDT) Message-ID: <40DAA206.4060200@dynamicsoft.com> Date: Thu, 24 Jun 2004 05:42:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D43@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D43@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. mikko.lonnfors@nokia.com wrote: >>>>I think it makes sense to use the same id attribute and space. My >>>>question is, if you did this, would a client that implemented the >>>>partial notification spec, but didnt know about a new >>>>element, peer to , properly construct a PIDF >> >>document when sent >> >>>>partial notifications that indicate changes or removal of >>>>elements? >>> >>> >>>Well, that might work but in order to be on a safe side it would be >>>better if clients would explicitly know about elements. If >>>attributes would have namespace this should not be a problem but as >>>there is no way to know if id attribute really is the same id >>>attribute there might be some nasty conflicts. >> >>Sorry, I don't quite follow here. What does attribute >>namespaces have to >>do with it? > > > Ok, let's try to sort this out. As far as I know attributes in XML don't > belong to any namespace. This means that if we want to have id attribute > in we need to separately define it within . This id > also has (in XML) nothing to do with id. > Now, if somebody would define a new element which would also have > id attribute (with different semantics) client would have no way to > distinguish this from id or from id. This more or less > means that client must be explicitly aware of element. I don't think that has to be the case. If you got an update that indicated that the document changed through the deletion of an element with id 3, the client could go through its current version of the document, select all elements under that have an "id" attribute with value 3, and delete them. This would work no matter what the name of those elements are. Similarly, when an element shows up in a partial document, the client finds the matching one in its current document by matching the element name and id value, and updates it. This could also work without the client needing to understand the semantics of device. For this to work though, I think the partial notification documents need to be clear that the algorithms apply to any child elements of , even ones not understood by the client, so long as they all have an "id" element. -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-bounces@ietf.org Thu Jun 24 17:30:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13997 for ; Thu, 24 Jun 2004 17:30:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbnh-0003sP-KL for simple-archive@ietf.org; Thu, 24 Jun 2004 17:30:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdb8s-00044o-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:48:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaUE-0004Gc-00; Thu, 24 Jun 2004 16:06:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdaIp-0008O4-US; Thu, 24 Jun 2004 15:54:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXQq-00047O-Ar; Thu, 24 Jun 2004 12:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdMjo-0007lY-30 for simple@megatron.ietf.org; Thu, 24 Jun 2004 01:25: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 BAA19310 for ; Thu, 24 Jun 2004 01:25:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdMjl-0000tb-QD for simple@ietf.org; Thu, 24 Jun 2004 01:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdMim-0000Wy-00 for simple@ietf.org; Thu, 24 Jun 2004 01:24:25 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdMiH-00009t-00 for simple@ietf.org; Thu, 24 Jun 2004 01:23:53 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5O5Ngbo029465 for ; Thu, 24 Jun 2004 01:23:43 -0400 (EDT) Message-ID: <40DA4811.9060704@dynamicsoft.com> Date: Wed, 23 Jun 2004 23:18:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 9: Etags mostly useless for insert X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit While working through the text on etags, I ran into an interesting issue. Its not clear its a problem, but its something that needs to be documented if we decide its not. The issue is that, when you do a conditional PUT (that is, a PUT with an If-Match containing an etag), the conditioning is based on the etag for *that* resource. There is no way to say, "perform this PUT on resource X, but only if the etag for resource Y has not changed". Why is this an issue? Well, let me give a concrete example. Lets say I have a basic buddy list that looks like this: Bill Doe Joe Smith Nancy Gross http://www.example.org/xcap/resource-lists/users/a/foo and lets consider the simplest etag scope (this issue doesnt matter what we decide to do for etag scopes per issue 8), where every resource in the document has the same value for its etag. Its important to understand that etags are associated with a resource. Even if we decide that all resources will share the same value for their etags, they still each have their own etags. Lets say that the current etag for this document (and all resources within it) is 2. I decide to insert a new entry, and so I do this: PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ resource-lists/list[@name="friends"]/entry[@name="Mikko"] If-Match: 1 You would think that this insertion would be done if the document had not been modified (i.e., its etag was still 1), but that is NOT what this request will do. The conditioning here means that the PUT is only done if the etag for the resource in the request URI has an etag of 1. Of course, the resource in the request URI doesnt yet exist (thats why its an insert), so this request will be rejected with a 412. Basically, there is no way to do an insert, and say, "don't do this insertion if the document hasn't changed since etag 1". You can say, "don't do this insert if this resource exists", by using an If-Not-Match: *. So, you can at least guarantee that what you think is an insertion, really is an insertion. So, the question is, is this a problem? I don't think so. Or, more concretely, I couldn't think of a use case where this was a problem. Consider the following example. Once again, we have the document above, and client A has a copy of it locally, in memory, with etag 1. Client 2 makes a change, and the change it makes is to delete the close-friends list. Client 1 then tries to do an insert into this list, and so it does: PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ resource-lists/list[@name="friends"]/ list[@name="close-friends"]/entry[@name="Paul"] Fortunately, this will request will fail with a 409, since the parent of entry[@name="Paul"] doesnt exist anymore. The client could then refetch the document and figure out why this error happened. So, no problem here. COnsider a different case. Client 1 has this list locally. Client 2 changes the name of "close-friends" to "really-close-friends". Same thing happens as the previous example. In yet another case, client 2 changes the subscribeable flag for close-friends from true to false. In this case, the insert done by client 1 will succeed. THe problem is that the client no longer has a correct copy of the document cached. If this is a problem, the client can refetch the document. I'll also note that, if you use the xcap package, this problem pretty much goes away. As far as I can tell, we have three choices about what to do about this "problem": 1. document the situation so its clear what etags do and don't do for you 2. instead of thinking about resources within a document as "not existing" when they aren't there, we can think about them as existing, but empty. If we stretch our imaginations a bit, we could think about assigning etags to empty resources. In that case, you basically never really do insertions; you only ever do modifications, and you might modify something from being empty to having actual value. In that case, you could usefully use etags to condition an "insertion" on whether or not the entire document has changed since you cached a copy. I consider this quite ugly. 3. Define an HTTP extension which allows you to condition a request based on the etag of a different request on the server. I think we should do 1. I think the costs of doing more complicated locking and transaction mechanisms (which is what we are talking about) are too high to pay for this functionality we want right now. If these things prove really important, we can work them in through xcap extensions. Comments and input are welcome. 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-bounces@ietf.org Thu Jun 24 17:30:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14034 for ; Thu, 24 Jun 2004 17:30:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbnr-0003uX-U2 for simple-archive@ietf.org; Thu, 24 Jun 2004 17:30:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdb8x-00045p-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:48:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaUE-0004Gc-04; Thu, 24 Jun 2004 16:06:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdaIh-0008MC-Nv; Thu, 24 Jun 2004 15:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXQp-00047J-Jg; Thu, 24 Jun 2004 12:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdMjn-0007lW-Es for simple@megatron.ietf.org; Thu, 24 Jun 2004 01:25: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 BAA19307 for ; Thu, 24 Jun 2004 01:25:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdMjl-0000tU-4e for simple@ietf.org; Thu, 24 Jun 2004 01:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdMil-0000Wq-00 for simple@ietf.org; Thu, 24 Jun 2004 01:24:24 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdMiE-00009s-00 for simple@ietf.org; Thu, 24 Jun 2004 01:23:50 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5O5Ndbo029462 for ; Thu, 24 Jun 2004 01:23:39 -0400 (EDT) Message-ID: <40DA3FBB.30906@dynamicsoft.com> Date: Wed, 23 Jun 2004 22:43:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Etags: Text Defining Option 3 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Please take a look at my email entitled "XCAP Issue 8: Etag Scope" before reading this. The following text is what we would need to put into the doc to support option 3.
Etags are associated with resources, with each resource being identified by an HTTP URI. In XCAP, these resources can correspond to a document, an XML element within a document, or an XML attribute within an element. Just as the structure of the document creates relationships between these resources, it also requires a creation of relationships amongst the Etags associated with those resources.
These relationships are defined using the notion of a scope. A scope is defined as a collection of resources, each of which shares the same value of the Etag. When any one of those resources changes, due to a PUT against that resource, the server assigns a new Etag for that resource. It will also assign that same Etag to all of the other resources within the same scope. A resource can only belong to one scope. A scope is always structured as the set of elements and attributes that begin with an element in the document, and include all child elements and their attributes, up to (and not including) any elements which are members of another scope. As a result, a scope can be thought of as either a sub-tree in the document, else as the difference between a sub-tree and sub-trees underneath it. One scope is said to be the parent of another scope if an element in the parent scope is a parent of an element in the child scope. Similarly, one scope is said to be the ancestor of another scope, if an element in the ancestor scope is an ancestor of an element in the descendant scope. A scope marker is a rule for determining when a scope starts and stops. It takes the form of a simple Xpath expression identifying a sequence of elements, by element name only, starting from the root of the document. For example, the Xpath expression "/foo/bar/baz" is a scope marker. This means that, within an instance document, all elements matching that expression represent the beginning of a scope (and thus possibly the end of another scope). Each application usage is responsible for identifying the scope markers for the documents used by that application usage. The scope markers for an application usage form a tree. Scope marker X is the parent of scope marker Y if the following are both true: The expression for X is a prefix for the expression for Y, For all other markers Z which are also prefixes for Y, X is not a prefix for any of those Z. It is important to understand that this tree of scope markers is static; its associated with the schema for the document, and doesn't change for different instance documents. An actual scope, however, is based on an instance document. It is uniquely identified by its root element and the markers that indicate the end of the scope. The root element is always an element that matches the Xpath expression corresponding to one of the scope markers (say, marker X). The markers identifying the end of the scope are all of the child markers of marker X. Formally, a resource is associated with a scope if that resource is an element, and that element is equal to, or a descendant of, the root element of the scope, and that element is not within the elements selected by evaluating the Xpath expressions that define the end of the scope. If the resource is an attribute, the resource is within the scope if the element containing that attribute is within the scope. Each document has a special scope, called the document scope, which contains the resource associated with the document itself, and includes any resources not otherwise included in a scope based on the above definitions. The document scope can be considered as the parent of all other scopes. Consider the following example. Lets say an application usage defines a schema for a simple document format. This document format has a single root element, , which can have any number of child elements, . Each element can have any number of child elements . Each element can have any number of child elements , and so on, all the way to . Every element, through , has a single attribute, id, which is a unique identifier for that element amongst its siblings. The application usages defines three scope markers. One marker is called "root", and its identified by the Xpath expression "/a". The next marker is called "layer 1" and its identified by the Xpath expression "/a/b/c". The third marker is called "layer 2" and its identified by the XPath expression "/a/b/c/d". depicts an instance document in graphical form. The dotted lines surround each of the 8 scopes that exist within the document. The 9th scope, the document scope, is not shown.
With this notion of scopes concretely defined, the rules for server processing of Etags can be defined. When a client modifies a resource, the server updates the etag for that resource. Call this new etag value "e-new". Furthermore, the server MUST set the etag for all other resources in the same scope to "e-new". The server then identifies all resources that belong in ancestor scopes to the one that was just modified, and it MUST modify their etags as well, setting them to "e-new". The etags in all other scopes MUST remain unchanged. The sharing of etags amongst resources is mandatory here in order to allow the client to maintain a synchronized view with the server on the etag structure.
Client processing of etags follows the HTTP specifications. Furthermore, because XCAP imposes additional requirements on how etags are shared amongst other resources, a client can implement the same algorithm as the server does, and keep track of the etags associated with each element, attribute and document stored on the server. It is useful to keep track of these when the client wants to perform conditional modifications to various places in the document. The client and server will remain in synchronization as long as no errors occur, or no other clients attempt to make a change to the same document. In the latter case, when the client performs a conditional PUT (using the If-Match or If-None-Match header fields), it will get a 412 error response. When that happens, the client cannot assume that any of the etags it currently possesses for the document in question are still valid. To re-syncrhonize, it can optionally perform a series of GET operations, which will return the current etags. The set of GET operations to perform is purely a local choice. What follows is an example algorithm which works well. If a PUT against a resource fails, the client looks at its local copy of the document, and figures out what scope its in. It then performs a GET against the root element in that scope. The result of this GET will update that section of the document tree. That will provide sufficient information (the content of the scope and its etag) for the client to re-do the request which just failed. To determine the etags and content for the other scopes, the client can perform the following steps. For each scope that is a sibling of the scope which was just fetched, the client performs a HEAD operation against the root element of that scope. The result of this HEAD operation will indicate the etags for each of those scopes. If the etag is unchanged from the one cached by the client, it knows that all elements within this scope, and their children, are unchanged (including their etags). If the HEAD operation indicates that the etag has changed, it applies the algorithm described in this paragraph to that scope as well. In addition to checking the etags of the siblings of the current scope, the client also performs a HEAD against all child scopes, in order to obtain their etags. The content of those scopes is already known, only their etags need to be determined.
-- 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-bounces@ietf.org Thu Jun 24 17:30:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14060 for ; Thu, 24 Jun 2004 17:30:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbnw-0003vK-Cx for simple-archive@ietf.org; Thu, 24 Jun 2004 17:30:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdb92-00046Z-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:48:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdaUF-0004Gc-02; Thu, 24 Jun 2004 16:06:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdaIe-0008Lx-PA; Thu, 24 Jun 2004 15:54:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXQo-00047C-U4; Thu, 24 Jun 2004 12:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdMfu-0007TK-2W for simple@megatron.ietf.org; Thu, 24 Jun 2004 01:21: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 BAA19124 for ; Thu, 24 Jun 2004 01:21:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdMfr-0007DE-Km for simple@ietf.org; Thu, 24 Jun 2004 01:21:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdMex-0006pu-00 for simple@ietf.org; Thu, 24 Jun 2004 01:20:28 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdMe9-00064b-00 for simple@ietf.org; Thu, 24 Jun 2004 01:19:37 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5O5JLbo029456 for ; Thu, 24 Jun 2004 01:19:21 -0400 (EDT) Message-ID: <40DA3EF5.2010001@dynamicsoft.com> Date: Wed, 23 Jun 2004 22:39:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 8: Etag Scope X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I've spent a bunch of time since the interim trying to work out details on how etag handling in XCAP needs to work, and to address the question asked by Aki, which is how the client keeps its etags synchronized with the server. As you may recall, at the last IETF meeting, we had consensus that etags could be scoped to various sub-trees in a document, rather than the whole document. In a separate note, I will send out the text that I created for the xcap specification which defines what this means. It concretely defines a "scope" as a set of resources (each resource having a unique HTTP URI) which all share the same value of an etag. Each resource can only be in one scope. A change in one resource in a scope causes a change in the etags for all other resources in that scope. A scope is structured as either a subtree, or as the intersection of a sub-tree with sub-trees beneath it. Unfortunately, it got really complicated, as you can see from the text. I think we need to simplify this a lot. I was able to come up with three possible simplifications that made sense. They are: 1. Revert to whats currently documented in xcap - there is only one scope, and its for the entire document. Thus, the document, and all elements and attributes within it, would have the same etag. This would make it very hard to have two people independently edit separate parts of the same document. If you want that, you need to have multiple documents. 2. Redefine a scope as just a tree (never the intersection of a tree with some of its sub-trees). Any elements outside of the defined scopes have NO etag. Here's an example. Lets say I have a document that looks like this: STUFF ; Thu, 24 Jun 2004 17:33:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdbqS-0004QF-Hl for simple-archive@ietf.org; Thu, 24 Jun 2004 17:33:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbCx-0004jW-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:52:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdaVm-0004Yf-00; Thu, 24 Jun 2004 16:07:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXSL-0004Qp-Hi; Thu, 24 Jun 2004 12:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdRQA-0004UY-BJ for simple@megatron.ietf.org; Thu, 24 Jun 2004 06:25: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 GAA22194 for ; Thu, 24 Jun 2004 06:25:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdRQ7-00075k-Dc for simple@ietf.org; Thu, 24 Jun 2004 06:25:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdRPB-0006jZ-00 for simple@ietf.org; Thu, 24 Jun 2004 06:24:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdROI-0005we-00 for simple@ietf.org; Thu, 24 Jun 2004 06:23:34 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5OANKbo029640; Thu, 24 Jun 2004 06:23:20 -0400 (EDT) Message-ID: <40DAAB83.20207@dynamicsoft.com> Date: Thu, 24 Jun 2004 06:22:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions References: <2038BCC78B1AD641891A0D1AE133DBB701797C38@esebe019.ntc.nokia.com> <40D1896C.3060408@dynamicsoft.com> In-Reply-To: <40D1896C.3060408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I mentioned below that I would send some pseudocode that describes the scope of what you'd have to do to get positional inserts working. Here it is. Its really rough, but I think it captures the essence of it. As you can see, its not all that complicated. Assume that the document is structed basically as a dom tree. onGET() { extract the node selector from the URI; obtain the document defined by the document selector; set the current context to the root of the document; for each step in the node selector { create a linked list of the children of the current context whose name matches the one defined by the step; for each predicate in the step { if the predicate is a position { extract the nth element in the linked list, where n is the position; } else if the predicate is an attribute selector { for each element in the linked list { if the element has an attribute with the given name, extract it; } } if more than one element was extracted, its an error; if no element was selected, return 404; else set the current context to the extracted element; } return the extracted element; } doPUT { perform a doGET() on the URI; if the result is not 404 { // this is a modification replace the selected element with the body of the PUT; perform a doGET() on this modified document; if the result is the element we just inserted { return 200 OK; } else { return 409; } } else { // this is an insertion strip off the last step from the URI; perform doGET() on the result; if that result was a 404 { return 409; } get the children of the selected element as a linked list; set current element to the first child; set counter to 1; if first predicate is a positional one { do { if name of current element matches the step we extracted { if position equals counter { insert before current element; done; } else { increment counter; } } } else { insert as last element; } do a doGET() on the modified document; if the element that is returned doesnt match what we just inserted return 409; else return 200; } } -Jonathan R. Jonathan Rosenberg wrote: > > > hisham.khartabil@nokia.com wrote: > >> Jonathan, >> >> Thanks for the analysis. >> >> Reading your analysis actually brings me to the opposite conclusion >> to the one you made. That is, we need positional insertions. There >> are so many rules, restriction, and guide lines that need to be >> educated to current and future designers of XCAP friendly schemas. >> Wouldn't it be a much better investment if we allow positional >> insertions now and avoid schema misdesign? > > > I don't think any of the guidelines represent a schema mis-design. > >> >> You haven't explicitly listed the issues with positional insertions, >> but instead you listed the problems that it solves. Can you please >> educate the rest of us what the real problems are with positional >> insertions? > > > It was just complexity. Positional insertions would require us to > support multiple predicates (i.e., more than one [] rule). We could > restrict it to just two in our case, and indeed, restrict the first > predicate to be a positional selector only. I think that might help the > complexity a bit. However, there is definitely more logic and code > required to support it than not. How much exactly? Depends on the > implementation. I'll send a separate note in the next day or so with a > pseudo-code view of what a minimal implementation would be, so folks can > get a sense of it. > > The meta-issue was that the whole idea with xcap is that what we are > generally doing is reading and writing a document from a server (like a > buddy list), but sometimes, you need to read or write a piece of it as > an optimization, so we have the notion of sub-document addressing. When > you view the design goal as reading and writing of entire documents with > sub-document operations as a performance optimization, things like > positional inserts teeter on the boundary between this view, and the > view of xcap as an XML database protocol. I think that, if we are > defining an XML database protocol, we would probably start from a > different approach, along the lines of XUpdate. > > I must say that, on the issue of positional inserts, I am on the fence. > I do see the "keep it barebones simple" argument, especially as it > relates to the view of xcap as an optimization around reading and > writing of documents. On the other hand, from a code perspective, I > don't think positional inserts is actually that complicated, and it > does, as Hisham pointed out, remove a lot of "schema design guidelines" > that I would otherwise need to introduce to deal with it. > > Comments from others? Even a "do positional inserts" or "dont do it" > response is helpful. > > 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-bounces@ietf.org Thu Jun 24 17:33:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14817 for ; Thu, 24 Jun 2004 17:33:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbqa-0004Rw-GT for simple-archive@ietf.org; Thu, 24 Jun 2004 17:33:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbDI-0004nS-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:52:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdaWQ-0004g6-00; Thu, 24 Jun 2004 16:08:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXSN-0004RI-9F; Thu, 24 Jun 2004 12:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdRTB-0004pm-Eu for simple@megatron.ietf.org; Thu, 24 Jun 2004 06:28: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 GAA22328 for ; Thu, 24 Jun 2004 06:28:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdRT8-0000Oi-IR for simple@ietf.org; Thu, 24 Jun 2004 06:28:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdRS9-00000h-00 for simple@ietf.org; Thu, 24 Jun 2004 06:27:34 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1BdRRJ-00076x-00 for simple@ietf.org; Thu, 24 Jun 2004 06:26:41 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5OAP7GP115272; Thu, 24 Jun 2004 10:25:07 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5OAP66Y273624; Thu, 24 Jun 2004 12:25:07 +0200 In-Reply-To: <40D1896C.3060408@dynamicsoft.com> To: Jonathan Rosenberg MIME-Version: 1.0 Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Avshalom Houri Date: Thu, 24 Jun 2004 13:25:01 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 24/06/2004 13:25:06, Serialize complete at 24/06/2004 13:25:06 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453655194==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --===============1453655194== Content-Type: multipart/alternative; boundary="=_alternative 003939B0C2256EBD_=" This is a multipart message in MIME format. --=_alternative 003939B0C2256EBD_= Content-Type: text/plain; charset="US-ASCII" Prefer to keep a simple base of XCAP and do extensions later. Avshalom Jonathan Rosenberg Sent by: simple-bounces@ietf.org 17/06/2004 03:07 PM To hisham.khartabil@nokia.com cc simple@ietf.org Subject Re: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions hisham.khartabil@nokia.com wrote: > Jonathan, > > Thanks for the analysis. > > Reading your analysis actually brings me to the opposite conclusion > to the one you made. That is, we need positional insertions. There > are so many rules, restriction, and guide lines that need to be > educated to current and future designers of XCAP friendly schemas. > Wouldn't it be a much better investment if we allow positional > insertions now and avoid schema misdesign? I don't think any of the guidelines represent a schema mis-design. > > You haven't explicitly listed the issues with positional insertions, > but instead you listed the problems that it solves. Can you please > educate the rest of us what the real problems are with positional > insertions? It was just complexity. Positional insertions would require us to support multiple predicates (i.e., more than one [] rule). We could restrict it to just two in our case, and indeed, restrict the first predicate to be a positional selector only. I think that might help the complexity a bit. However, there is definitely more logic and code required to support it than not. How much exactly? Depends on the implementation. I'll send a separate note in the next day or so with a pseudo-code view of what a minimal implementation would be, so folks can get a sense of it. The meta-issue was that the whole idea with xcap is that what we are generally doing is reading and writing a document from a server (like a buddy list), but sometimes, you need to read or write a piece of it as an optimization, so we have the notion of sub-document addressing. When you view the design goal as reading and writing of entire documents with sub-document operations as a performance optimization, things like positional inserts teeter on the boundary between this view, and the view of xcap as an XML database protocol. I think that, if we are defining an XML database protocol, we would probably start from a different approach, along the lines of XUpdate. I must say that, on the issue of positional inserts, I am on the fence. I do see the "keep it barebones simple" argument, especially as it relates to the view of xcap as an optimization around reading and writing of documents. On the other hand, from a code perspective, I don't think positional inserts is actually that complicated, and it does, as Hisham pointed out, remove a lot of "schema design guidelines" that I would otherwise need to introduce to deal with it. Comments from others? Even a "do positional inserts" or "dont do it" response is helpful. 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 --=_alternative 003939B0C2256EBD_= Content-Type: text/html; charset="US-ASCII"
Prefer to keep a simple base of XCAP and do extensions later.

Avshalom



Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Sent by: simple-bounces@ietf.org

17/06/2004 03:07 PM

To
hisham.khartabil@nokia.com
cc
simple@ietf.org
Subject
Re: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions







hisham.khartabil@nokia.com wrote:

> Jonathan,
>
> Thanks for the analysis.
>
> Reading your analysis actually brings me to the opposite conclusion
> to the one you made. That is, we need positional insertions.  There
> are so many rules, restriction, and guide lines that need to be
> educated to current and future designers of XCAP friendly schemas.
> Wouldn't it be a much better investment if we allow positional
> insertions now and avoid schema misdesign?

I don't think any of the guidelines represent a schema mis-design.

>
> You haven't explicitly listed the issues with positional insertions,
> but instead you listed the problems that it solves. Can you please
> educate the rest of us what the real problems are with positional
> insertions?

It was just complexity. Positional insertions would require us to
support multiple predicates (i.e., more than one [] rule). We could
restrict it to just two in our case, and indeed, restrict the first
predicate to be a positional selector only. I think that might help the
complexity a bit. However, there is definitely more logic and code
required to support it than not. How much exactly? Depends on the
implementation. I'll send a separate note in the next day or so with a
pseudo-code view of what a minimal implementation would be, so folks can
get a sense of it.

The meta-issue was that the whole idea with xcap is that what we are
generally doing is reading and writing a document from a server (like a
buddy list), but sometimes, you need to read or write a piece of it as
an optimization, so we have the notion of sub-document addressing. When
you view the design goal as reading and writing of entire documents with
sub-document operations as a performance optimization, things like
positional inserts teeter on the boundary between this view, and the
view of xcap as an XML database protocol. I think that, if we are
defining an XML database protocol, we would probably start from a
different approach, along the lines of XUpdate.

I must say that, on the issue of positional inserts, I am on the fence.
I do see the "keep it barebones simple" argument, especially as it
relates to the view of xcap as an optimization around reading and
writing of documents. On the other hand, from a code perspective, I
don't think positional inserts is actually that complicated, and it
does, as Hisham pointed out, remove a lot of "schema design guidelines"
that I would otherwise need to introduce to deal with it.

Comments from others? Even a "do positional inserts" or "dont do it"
response is helpful.

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
--=_alternative 003939B0C2256EBD_=-- --===============1453655194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1453655194==-- From simple-bounces@ietf.org Thu Jun 24 17:33:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14865 for ; Thu, 24 Jun 2004 17:33:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbqj-0004TT-Qt for simple-archive@ietf.org; Thu, 24 Jun 2004 17:33:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbDf-0004qw-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:53:16 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdaWw-0004lL-00; Thu, 24 Jun 2004 16:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXSS-0004Ra-BA; Thu, 24 Jun 2004 12:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdRpY-0006Mo-96 for simple@megatron.ietf.org; Thu, 24 Jun 2004 06:51: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 GAA24289 for ; Thu, 24 Jun 2004 06:51:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdRpV-0001Mh-HB for simple@ietf.org; Thu, 24 Jun 2004 06:51:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdRoe-0000zx-00 for simple@ietf.org; Thu, 24 Jun 2004 06:50:48 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdRnn-0000Wo-00 for simple@ietf.org; Thu, 24 Jun 2004 06:49:55 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5OAnVbo029654 for ; Thu, 24 Jun 2004 06:49:37 -0400 (EDT) Message-ID: <40DAB1A6.1020007@dynamicsoft.com> Date: Thu, 24 Jun 2004 06:49:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 8: Etag Scope X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit [resending, didnt seem to go through the first time] Folks, I've spent a bunch of time since the interim trying to work out details on how etag handling in XCAP needs to work, and to address the question asked by Aki, which is how the client keeps its etags synchronized with the server. As you may recall, at the last IETF meeting, we had consensus that etags could be scoped to various sub-trees in a document, rather than the whole document. In a separate note, I will send out the text that I created for the xcap specification which defines what this means. It concretely defines a "scope" as a set of resources (each resource having a unique HTTP URI) which all share the same value of an etag. Each resource can only be in one scope. A change in one resource in a scope causes a change in the etags for all other resources in that scope. A scope is structured as either a subtree, or as the intersection of a sub-tree with sub-trees beneath it. Unfortunately, it got really complicated, as you can see from the text. I think we need to simplify this a lot. I was able to come up with three possible simplifications that made sense. They are: 1. Revert to whats currently documented in xcap - there is only one scope, and its for the entire document. Thus, the document, and all elements and attributes within it, would have the same etag. This would make it very hard to have two people independently edit separate parts of the same document. If you want that, you need to have multiple documents. 2. Redefine a scope as just a tree (never the intersection of a tree with some of its sub-trees). Any elements outside of the defined scopes have NO etag. Here's an example. Lets say I have a document that looks like this: STUFF ; Thu, 24 Jun 2004 17:33:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbql-0004Tv-MD for simple-archive@ietf.org; Thu, 24 Jun 2004 17:33:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbDl-0004s1-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:53:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdaXA-0004nS-00; Thu, 24 Jun 2004 16:09:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXSS-0004SM-UB; Thu, 24 Jun 2004 12:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdRpZ-0006Ms-NT for simple@megatron.ietf.org; Thu, 24 Jun 2004 06:51: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 GAA24298 for ; Thu, 24 Jun 2004 06:51:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdRpW-0001Ms-SI for simple@ietf.org; Thu, 24 Jun 2004 06:51:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdRof-00010E-00 for simple@ietf.org; Thu, 24 Jun 2004 06:50:51 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdRo6-0000dR-00 for simple@ietf.org; Thu, 24 Jun 2004 06:50:14 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5OAo4bo029657 for ; Thu, 24 Jun 2004 06:50:05 -0400 (EDT) Message-ID: <40DAB1C8.7060207@dynamicsoft.com> Date: Thu, 24 Jun 2004 06:49:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Etags: Text Defining Option 3 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit [resend] Please take a look at my email entitled "XCAP Issue 8: Etag Scope" before reading this. The following text is what we would need to put into the doc to support option 3.
Etags are associated with resources, with each resource being identified by an HTTP URI. In XCAP, these resources can correspond to a document, an XML element within a document, or an XML attribute within an element. Just as the structure of the document creates relationships between these resources, it also requires a creation of relationships amongst the Etags associated with those resources.
These relationships are defined using the notion of a scope. A scope is defined as a collection of resources, each of which shares the same value of the Etag. When any one of those resources changes, due to a PUT against that resource, the server assigns a new Etag for that resource. It will also assign that same Etag to all of the other resources within the same scope. A resource can only belong to one scope. A scope is always structured as the set of elements and attributes that begin with an element in the document, and include all child elements and their attributes, up to (and not including) any elements which are members of another scope. As a result, a scope can be thought of as either a sub-tree in the document, else as the difference between a sub-tree and sub-trees underneath it. One scope is said to be the parent of another scope if an element in the parent scope is a parent of an element in the child scope. Similarly, one scope is said to be the ancestor of another scope, if an element in the ancestor scope is an ancestor of an element in the descendant scope. A scope marker is a rule for determining when a scope starts and stops. It takes the form of a simple Xpath expression identifying a sequence of elements, by element name only, starting from the root of the document. For example, the Xpath expression "/foo/bar/baz" is a scope marker. This means that, within an instance document, all elements matching that expression represent the beginning of a scope (and thus possibly the end of another scope). Each application usage is responsible for identifying the scope markers for the documents used by that application usage. The scope markers for an application usage form a tree. Scope marker X is the parent of scope marker Y if the following are both true: The expression for X is a prefix for the expression for Y, For all other markers Z which are also prefixes for Y, X is not a prefix for any of those Z. It is important to understand that this tree of scope markers is static; its associated with the schema for the document, and doesn't change for different instance documents. An actual scope, however, is based on an instance document. It is uniquely identified by its root element and the markers that indicate the end of the scope. The root element is always an element that matches the Xpath expression corresponding to one of the scope markers (say, marker X). The markers identifying the end of the scope are all of the child markers of marker X. Formally, a resource is associated with a scope if that resource is an element, and that element is equal to, or a descendant of, the root element of the scope, and that element is not within the elements selected by evaluating the Xpath expressions that define the end of the scope. If the resource is an attribute, the resource is within the scope if the element containing that attribute is within the scope. Each document has a special scope, called the document scope, which contains the resource associated with the document itself, and includes any resources not otherwise included in a scope based on the above definitions. The document scope can be considered as the parent of all other scopes. Consider the following example. Lets say an application usage defines a schema for a simple document format. This document format has a single root element, , which can have any number of child elements, . Each element can have any number of child elements . Each element can have any number of child elements , and so on, all the way to . Every element, through , has a single attribute, id, which is a unique identifier for that element amongst its siblings. The application usages defines three scope markers. One marker is called "root", and its identified by the Xpath expression "/a". The next marker is called "layer 1" and its identified by the Xpath expression "/a/b/c". The third marker is called "layer 2" and its identified by the XPath expression "/a/b/c/d". depicts an instance document in graphical form. The dotted lines surround each of the 8 scopes that exist within the document. The 9th scope, the document scope, is not shown.
With this notion of scopes concretely defined, the rules for server processing of Etags can be defined. When a client modifies a resource, the server updates the etag for that resource. Call this new etag value "e-new". Furthermore, the server MUST set the etag for all other resources in the same scope to "e-new". The server then identifies all resources that belong in ancestor scopes to the one that was just modified, and it MUST modify their etags as well, setting them to "e-new". The etags in all other scopes MUST remain unchanged. The sharing of etags amongst resources is mandatory here in order to allow the client to maintain a synchronized view with the server on the etag structure.
Client processing of etags follows the HTTP specifications. Furthermore, because XCAP imposes additional requirements on how etags are shared amongst other resources, a client can implement the same algorithm as the server does, and keep track of the etags associated with each element, attribute and document stored on the server. It is useful to keep track of these when the client wants to perform conditional modifications to various places in the document. The client and server will remain in synchronization as long as no errors occur, or no other clients attempt to make a change to the same document. In the latter case, when the client performs a conditional PUT (using the If-Match or If-None-Match header fields), it will get a 412 error response. When that happens, the client cannot assume that any of the etags it currently possesses for the document in question are still valid. To re-syncrhonize, it can optionally perform a series of GET operations, which will return the current etags. The set of GET operations to perform is purely a local choice. What follows is an example algorithm which works well. If a PUT against a resource fails, the client looks at its local copy of the document, and figures out what scope its in. It then performs a GET against the root element in that scope. The result of this GET will update that section of the document tree. That will provide sufficient information (the content of the scope and its etag) for the client to re-do the request which just failed. To determine the etags and content for the other scopes, the client can perform the following steps. For each scope that is a sibling of the scope which was just fetched, the client performs a HEAD operation against the root element of that scope. The result of this HEAD operation will indicate the etags for each of those scopes. If the etag is unchanged from the one cached by the client, it knows that all elements within this scope, and their children, are unchanged (including their etags). If the HEAD operation indicates that the etag has changed, it applies the algorithm described in this paragraph to that scope as well. In addition to checking the etags of the siblings of the current scope, the client also performs a HEAD against all child scopes, in order to obtain their etags. The content of those scopes is already known, only their etags need to be determined.
-- 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-bounces@ietf.org Thu Jun 24 17:33:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14927 for ; Thu, 24 Jun 2004 17:33:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdbqw-0004VA-Cz for simple-archive@ietf.org; Thu, 24 Jun 2004 17:33:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbE2-0004um-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 16:53:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdaXd-0004rn-00; Thu, 24 Jun 2004 16:09:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXST-0004SR-Gb; Thu, 24 Jun 2004 12:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdRqI-0006PH-AQ for simple@megatron.ietf.org; Thu, 24 Jun 2004 06:52: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 GAA24303 for ; Thu, 24 Jun 2004 06:52:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdRqF-0001hr-JZ for simple@ietf.org; Thu, 24 Jun 2004 06:52:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdRpG-0001Kl-00 for simple@ietf.org; Thu, 24 Jun 2004 06:51:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdRoJ-0000dU-00 for simple@ietf.org; Thu, 24 Jun 2004 06:50:27 -0400 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5OAoIbo029660 for ; Thu, 24 Jun 2004 06:50:18 -0400 (EDT) Message-ID: <40DAB1D5.10802@dynamicsoft.com> Date: Thu, 24 Jun 2004 06:49:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] XCAP Issue 9: Etags mostly useless for insert X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit [resend] While working through the text on etags, I ran into an interesting issue. Its not clear its a problem, but its something that needs to be documented if we decide its not. The issue is that, when you do a conditional PUT (that is, a PUT with an If-Match containing an etag), the conditioning is based on the etag for *that* resource. There is no way to say, "perform this PUT on resource X, but only if the etag for resource Y has not changed". Why is this an issue? Well, let me give a concrete example. Lets say I have a basic buddy list that looks like this: Bill Doe Joe Smith Nancy Gross http://www.example.org/xcap/resource-lists/users/a/foo and lets consider the simplest etag scope (this issue doesnt matter what we decide to do for etag scopes per issue 8), where every resource in the document has the same value for its etag. Its important to understand that etags are associated with a resource. Even if we decide that all resources will share the same value for their etags, they still each have their own etags. Lets say that the current etag for this document (and all resources within it) is 2. I decide to insert a new entry, and so I do this: PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ resource-lists/list[@name="friends"]/entry[@name="Mikko"] If-Match: 1 You would think that this insertion would be done if the document had not been modified (i.e., its etag was still 1), but that is NOT what this request will do. The conditioning here means that the PUT is only done if the etag for the resource in the request URI has an etag of 1. Of course, the resource in the request URI doesnt yet exist (thats why its an insert), so this request will be rejected with a 412. Basically, there is no way to do an insert, and say, "don't do this insertion if the document hasn't changed since etag 1". You can say, "don't do this insert if this resource exists", by using an If-Not-Match: *. So, you can at least guarantee that what you think is an insertion, really is an insertion. So, the question is, is this a problem? I don't think so. Or, more concretely, I couldn't think of a use case where this was a problem. Consider the following example. Once again, we have the document above, and client A has a copy of it locally, in memory, with etag 1. Client 2 makes a change, and the change it makes is to delete the close-friends list. Client 1 then tries to do an insert into this list, and so it does: PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ resource-lists/list[@name="friends"]/ list[@name="close-friends"]/entry[@name="Paul"] Fortunately, this will request will fail with a 409, since the parent of entry[@name="Paul"] doesnt exist anymore. The client could then refetch the document and figure out why this error happened. So, no problem here. COnsider a different case. Client 1 has this list locally. Client 2 changes the name of "close-friends" to "really-close-friends". Same thing happens as the previous example. In yet another case, client 2 changes the subscribeable flag for close-friends from true to false. In this case, the insert done by client 1 will succeed. THe problem is that the client no longer has a correct copy of the document cached. If this is a problem, the client can refetch the document. I'll also note that, if you use the xcap package, this problem pretty much goes away. As far as I can tell, we have three choices about what to do about this "problem": 1. document the situation so its clear what etags do and don't do for you 2. instead of thinking about resources within a document as "not existing" when they aren't there, we can think about them as existing, but empty. If we stretch our imaginations a bit, we could think about assigning etags to empty resources. In that case, you basically never really do insertions; you only ever do modifications, and you might modify something from being empty to having actual value. In that case, you could usefully use etags to condition an "insertion" on whether or not the entire document has changed since you cached a copy. I consider this quite ugly. 3. Define an HTTP extension which allows you to condition a request based on the etag of a different request on the server. I think we should do 1. I think the costs of doing more complicated locking and transaction mechanisms (which is what we are talking about) are too high to pay for this functionality we want right now. If these things prove really important, we can work them in through xcap extensions. Comments and input are welcome. 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-bounces@ietf.org Thu Jun 24 18:06:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17850 for ; Thu, 24 Jun 2004 18:06:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdcMt-0002yQ-HS for simple-archive@ietf.org; Thu, 24 Jun 2004 18:06:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbXC-00012l-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 17:13:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdasD-0001Bw-02; Thu, 24 Jun 2004 16:31:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdamw-0001pV-RK; Thu, 24 Jun 2004 16:25:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXUY-00058i-JO; Thu, 24 Jun 2004 12:54:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdVMB-00021P-0o for simple@megatron.ietf.org; Thu, 24 Jun 2004 10:37: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 KAA18236 for ; Thu, 24 Jun 2004 10:37:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdVMA-00052R-1Z for simple@ietf.org; Thu, 24 Jun 2004 10:37:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdVLB-0004e3-00 for simple@ietf.org; Thu, 24 Jun 2004 10:36:38 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BdVK9-0003sh-00 for simple@ietf.org; Thu, 24 Jun 2004 10:35:33 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i5OEZ2Rn005424 for ; Thu, 24 Jun 2004 09:35:02 -0500 (CDT) Message-ID: <40DAE695.818391E1@alcatel.com> Date: Thu, 24 Jun 2004 09:35:01 -0500 From: Jing Qian Organization: Alcatel X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB701797B9D@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] How to get SIP phone presence info X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, I am working on the Presence Server to get the presence status of a specific user's SIP phone - on the call , not on the call - a user based SIP phone status. Currently, there is no SIP server or SIP PBX standard available. Would anybody give me an idea how can the presence status of a SIP phone be published to a Presence Server by a SIP server/PBX or other service? Any idea will be appreciated. Thanks in advance. Jing hisham.khartabil@nokia.com wrote: > There are scenarios where a subscriber has created a filter in a subscription but wishes to replace that filter with another. There were 2 options presented at the interim with me proposing to adopt the 2nd as the solution. > > Option 1: remove and add a filter in the same subscription > > > xmlns:pidf="urn:ietf:params:xml:ns:pidf"> > > > > //pidf:tuple/pidf:status/pidf:basic > > > > > Option 2: Allow a filter to be replaced re-using the same filter id > > > xmlns:pidf="urn:ietf:params:xml:ns:pidf"> > > > //pidf:tuple/pidf:status/pidf:basic > > > > > No one objected to option 2. If there aren't any objections on the mailing list, I will add some clarification text on this issue. > > Regards, > Hisham > > _______________________________________________ > 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-bounces@ietf.org Thu Jun 24 18:07:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18202 for ; Thu, 24 Jun 2004 18:07:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdcNt-0003A9-6w for simple-archive@ietf.org; Thu, 24 Jun 2004 18:07:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbYk-0001Hc-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 17:15:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdasP-0001C2-00; Thu, 24 Jun 2004 16:31:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdaiR-0001aT-7C; Thu, 24 Jun 2004 16:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXUD-00052t-5L; Thu, 24 Jun 2004 12:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdUEd-0006Zc-LB for simple@megatron.ietf.org; Thu, 24 Jun 2004 09:25: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 JAA10854 for ; Thu, 24 Jun 2004 09:25:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdUEc-0000Wx-Sd for simple@ietf.org; Thu, 24 Jun 2004 09:25:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdUDi-0000AN-00 for simple@ietf.org; Thu, 24 Jun 2004 09:24:51 -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 1BdUDI-0007a7-00 for simple@ietf.org; Thu, 24 Jun 2004 09:24:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2004 06:27:33 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5ODNl4N021395; Thu, 24 Jun 2004 06:23:48 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJR28738; Thu, 24 Jun 2004 09:23:46 -0400 (EDT) Message-ID: <40DAD5E1.4010007@cisco.com> Date: Thu, 24 Jun 2004 09:23:45 -0400 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: Guido Gybels Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, paulej@packetizer.com, a.vwijk@viataal.nl, simple@ietf.org, gv@trace.wisc.edu, toip@snowshore.com, gunnar.hellstrom@omnitor.se, smundra@telogy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guido Gybels wrote: > Gregg, > > I agree with all you say and I'd like to add an important point. It seems we are going back to discussions we had a year ago. Messaging can NOT replace interactive text anymore than it replaces voice communication for hearing people. I have attached the short paper that I wrote for last year's IETF discussion on this topic. > > One critical issue is that of relay communications: if you want to use a relay service for text-to-speech, like for example RNID Typetalk, messaging simply does not work at all. Streamed, character by character text is a MUST for that type of conversation. Maybe I missed something, but I don't recall anyone here recently suggesting that messaging *should* replace interactive text. I believe Cullen was asking if interactive text could be integrated into the MSRP work. (Sorry Cullen if I misrepresent you.) I suggested that IM *clients* might be modified to support *either* message exchange or real time text. In that scenario, which protocol to use would be negotiated by the two endpoints. If one can do both IM and RTT, and the other can only do IM, then the conversation would use IM. (Maybe I'm wrong, but I suspect if the choice is between IM and nothing, that you would prefer IM, regardless of how unsuitable you find it.) I accept your point that IM isn't suitable for a bunch of the communication needs of the hearing impaired. (Among others.) But I also want you to accept that RTT isn't a suitable substitute for IM in the applications that millions (actually probably 10s or 100s of millions) of people use it everyday. So RTT is a different medium that IM. However it is in some ways more closely connected to IM than to voice or video, because both work with text. The choice seems to be whether RTT is supported by a unique set of (hard or soft) devices, or whether it is supported by the some or all of the devices that already support voice, video, or IM. If it is supported only by special devices, then you will only be using it to communicate with those who bother to have such a device. If you can arrange for it to be supported by more common devices, then you will have a broader range of people to communicate with. It seems to me there is at least a possibility of getting typical IM devices to support RTT - more likely than getting voice or video phones to do so. Paul > Best wishes, > > Guido > > > > > Guido Gybels > Director of New Technologies > > RNID, 19-23 Featherstone Street > London EC1Y 8SL, UK > Tel +44(0)20-7294 3713 > Fax +44(0)20-7296 8069 > > > >>>>"Gregg Vanderheiden" 06/23/04 04:25pm >>> >>> > Hi all > > A sixpack of quick comments. > > 1 - if you don't have anything else, a phone keypad for text entry and even > a 12 character display is wonderful. The alternative is nothing. > > 2 - if possible, any type or size of keyboard with one key per character is > better easier simpler faster. > > 3 - real time text (rather than messages) is much better for conversations. > 4 > - even 5 second message delay breaks all of our conversational protocols > and expectations and leads to interruptions, misinterpretations of intent > etc -- especially if one of the communicators is used to speech. Delays > beyond this are another form of communication (messaging) which is not bad > it just is not conversation. It is definitely communication, interaction, > a lot of things. But it differs from conversation as we know it. > > 5 - it would be great to have bridges between messaging and conversation > technologies to use when conversation technologies are not possible or > available for some reason. > > 6 - messaging is preferred by some and for some situations. It is not > inferior - it is just different. It will be better at some tasks and worse > at others. > > > > Gregg > > -- ------------------------------ > Gregg C Vanderheiden Ph.D. > Professor - Ind. Engr. & BioMed Engr. > Director - Trace R & D Center > University of Wisconsin-Madison > > - > This list is maintained by Snowshore Networks - http://www.snowshore.com > All comments on this list are the comments of the message originators and > Snowshore is not to be held responsible for any actions or comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/toip_archive/maillist.html > > > > > ************************************************************************ > This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity to > whom they are addressed. Any views or opinions expressed > are solely those of the author and do not necessarily represent > RNID policy. > > If you are not the intended recipient you are advised that any > use, dissemination, forwarding, printing or copying of this > email is strictly prohibited. > > If you have received this email in error please notify the RNID > Helpdesk by telephone on: +44 (0) 207 296 8282. > > The Royal National Institute for Deaf People > Registered Office 19-23 Featherstone Street > London EC1Y 8SL No. 454169 (England) > Registered Charity No. 207720 > ************************************************************************ > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 18:08:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18365 for ; Thu, 24 Jun 2004 18:08:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdcON-0003FT-EB for simple-archive@ietf.org; Thu, 24 Jun 2004 18:08:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbZP-0001O7-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 17:15:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdasT-0001Bw-03; Thu, 24 Jun 2004 16:31:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdag4-0001Tc-SD; Thu, 24 Jun 2004 16:18:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXTv-0004wA-Vm; Thu, 24 Jun 2004 12:53:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdTjx-00030b-5I for simple@megatron.ietf.org; Thu, 24 Jun 2004 08:54: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 IAA07718 for ; Thu, 24 Jun 2004 08:54:03 -0400 (EDT) From: hgs@cs.columbia.edu Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdTjw-0003R7-Di for simple@ietf.org; Thu, 24 Jun 2004 08:54:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdTjG-00032N-00 for simple@ietf.org; Thu, 24 Jun 2004 08:53:23 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BdTiA-0002Z4-00 for simple@ietf.org; Thu, 24 Jun 2004 08:52:14 -0400 Received: from hydra.cs.columbia.edu (IDENT:dDFp7cgq8ySlGHF+bXXi0+BzY3ijZH16@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5OCqAfq025082 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 24 Jun 2004 08:52:10 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:tqQu7HCvIP5kuFnbs4+Xn9r76zfh8aWm@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id i5OCq9Xt025770; Thu, 24 Jun 2004 08:52:10 -0400 Received: from 68.247.247.145 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Thu, 24 Jun 2004 08:52:10 -0400 (EDT) Message-ID: <1160.68.247.247.145.1088081530.squirrel@webmail.cs.columbia.edu> In-Reply-To: <40DAA206.4060200@dynamicsoft.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF030C9D43@esebe004.ntc.nokia.com> <40DAA206.4060200@dynamicsoft.com> Date: Thu, 24 Jun 2004 08:52:10 -0400 (EDT) Subject: Re: [Simple] RPID: what does tuple-type really mean? To: "Jonathan Rosenberg" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.6.23.104936 X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, __SANE_MSGID 0, __IN_REP_TO 0, __REFERENCES 0, NO_REAL_NAME 0.000, __TO_MALFORMED_2 0, __USER_AGENT 0, __MIME_VERSION 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __HAS_X_PRIORITY 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, __HAS_MSGID 0, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 8bit Cc: simple@ietf.org, mikko.lonnfors@nokia.com, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Before adding complexity, I still don't see why provides any real value. Can we agree on the requirements and objectives first, before designing mechanisms? > I don't think that has to be the case. If you got an update that > indicated that the document changed through the deletion of an element > with id 3, the client could go through its current version of the > document, select all elements under that have an "id" > attribute with value 3, and delete them. This would work no matter what > the name of those elements are. > > Similarly, when an element shows up in a partial document, the client > finds the matching one in its current document by matching the element > name and id value, and updates it. This could also work without the > client needing to understand the semantics of device. > > For this to work though, I think the partial notification documents need > to be clear that the algorithms apply to any child elements of > , even ones not understood by the client, so long as they all > have an "id" element. > > -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-bounces@ietf.org Thu Jun 24 19:14:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27938 for ; Thu, 24 Jun 2004 19:14:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddMP-0001i0-Uu for simple-archive@ietf.org; Thu, 24 Jun 2004 19:10:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdcsk-00020j-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 18:39:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdcBR-0000iD-01; Thu, 24 Jun 2004 17:55:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdc39-0007j2-6e; Thu, 24 Jun 2004 17:46:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbS8-0002M7-7a; Thu, 24 Jun 2004 17:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdagn-0006rD-3V for simple@megatron.ietf.org; Thu, 24 Jun 2004 16:19: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 QAA25028 for ; Thu, 24 Jun 2004 16:19:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdagl-00071C-R5 for simple@ietf.org; Thu, 24 Jun 2004 16:19:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bda7M-0000O5-00 for simple@ietf.org; Thu, 24 Jun 2004 15:42:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdZd2-00028j-00 for simple@ietf.org; Thu, 24 Jun 2004 15:11:20 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdZXc-0005gO-Kd for simple@ietf.org; Thu, 24 Jun 2004 15:05:44 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5OJ59428497; Thu, 24 Jun 2004 15:05:10 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 15:05:10 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710128B097@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: aki.neimi@nokia.com Date: Thu, 24 Jun 2004 15:04:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: simple@ietf.org Subject: [Simple] Comments on PUBLISH Draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1276470245==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1276470245== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45A1E.259F2770" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45A1E.259F2770 Content-Type: text/plain; charset="ISO-8859-1" Hey Aki, I was reading through the PUBLISH draft this morning and noticed something that I think we need to make some changes to the draft to cover off. Specifically, on page 8, table 1 shows 4 possible scenarios. However, if you look at this table as a truth table, the three variables (Body, SIP-If-Match, and Expires = 0) suggests 2^3 results, or 8 results. I believe that these error scenarios should be explicitly covered off so folks don't think they can update the state and remove at the same time, while others consider that to be an error. I think we simply forgot about these scenarios when going through the draft in earlier prototypes. Specifically: * Contains a body, no SIM, expires = 0: should elicit a 423 because the expires interval on the initial publish must be non-zero (it makes no sense otherwise). * Contains a body, has SIM, expires = 0: should elicit a 423 because modify the state and then immediately removing it makes no sense (may be controversial). * No body, no SIM, expires = 0: should elicit a 412 because there's no way we can match an ETag if none was supplied as part of the remove operation. * No body, no SIM, expires > 0: should elicit a 400 response because you'd be creating an initial publication with no state information (makes no sense, but may be controversial). Regards, Brian ------_=_NextPart_001_01C45A1E.259F2770 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Comments on PUBLISH Draft

Hey Aki,

I was reading through the PUBLISH draft this morning = and noticed something that I think we need to make some changes to the = draft to cover off. Specifically, on page 8, table 1 shows 4 possible = scenarios. However, if you look at this table as a truth table, the = three variables (Body, SIP-If-Match, and Expires =3D 0) suggests 2^3 = results, or 8 results. I believe that these error scenarios should be = explicitly covered off so folks don't think they can update the state = and remove at the same time, while others consider that to be an error. = I think we simply forgot about these scenarios when going through the = draft in earlier prototypes.

Specifically:

*       Contains a = body, no SIM, expires =3D 0: should elicit a 423 because the expires = interval on the initial publish must be non-zero (it makes no sense = otherwise).

*       Contains a = body, has SIM, expires =3D 0: should elicit a 423 because modify the = state and then immediately removing it makes no sense (may be = controversial).

*       No body, no = SIM, expires =3D 0: should elicit a 412 because there's no way we can = match an ETag if none was supplied as part of the remove = operation.

*       No body, no = SIM, expires > 0: should elicit a 400 response because you'd be = creating an initial publication with no state information (makes no = sense, but may be controversial).

Regards,

Brian

------_=_NextPart_001_01C45A1E.259F2770-- --===============1276470245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1276470245==-- From simple-bounces@ietf.org Thu Jun 24 19:14:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27962 for ; Thu, 24 Jun 2004 19:14:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddMN-0001hV-Ba for simple-archive@ietf.org; Thu, 24 Jun 2004 19:10:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdcsc-0001xa-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 18:39:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdcBQ-0000iD-01; Thu, 24 Jun 2004 17:55:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdc4A-0007qS-OF; Thu, 24 Jun 2004 17:47:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbSE-0002QI-4v; Thu, 24 Jun 2004 17:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdah3-0006tv-0B for simple@megatron.ietf.org; Thu, 24 Jun 2004 16:19:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25066 for ; Thu, 24 Jun 2004 16:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdah1-000749-A8 for simple@ietf.org; Thu, 24 Jun 2004 16:19:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bda7f-0000Rn-00 for simple@ietf.org; Thu, 24 Jun 2004 15:43:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdZd7-0002CT-00 for simple@ietf.org; Thu, 24 Jun 2004 15:11:25 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdZX1-0005dv-Ul for simple@ietf.org; Thu, 24 Jun 2004 15:05:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5OJ4M428394; Thu, 24 Jun 2004 15:04:23 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 15:04:18 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710128B090@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: aki.niemi@nokia.com Date: Thu, 24 Jun 2004 15:04:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: simple@ietf.org Subject: [Simple] Comments on PUBLISH Draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2027798002==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2027798002== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45A1E.0787F2C8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45A1E.0787F2C8 Content-Type: text/plain; charset="ISO-8859-1" Hey Aki, I was reading through the PUBLISH draft this morning and noticed something that I think we need to make some changes to the draft to cover off. Specifically, on page 8, table 1 shows 4 possible scenarios. However, if you look at this table as a truth table, the three variables (Body, SIP-If-Match, and Expires = 0) suggests 2^3 results, or 8 results. I believe that these error scenarios should be explicitly covered off so folks don't think they can update the state and remove at the same time, while others consider that to be an error. I think we simply forgot about these scenarios when going through the draft in earlier prototypes. Specifically: * Contains a body, no SIM, expires = 0: should elicit a 423 because the expires interval on the initial publish must be non-zero (it makes no sense otherwise). * Contains a body, has SIM, expires = 0: should elicit a 423 because modify the state and then immediately removing it makes no sense (may be controversial). * No body, no SIM, expires = 0: should elicit a 412 because there's no way we can match an ETag if none was supplied as part of the remove operation. * No body, no SIM, expires > 0: should elicit a 400 response because you'd be creating an initial publication with no state information (makes no sense, but may be controversial). Regards, Brian ------_=_NextPart_001_01C45A1E.0787F2C8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Comments on PUBLISH Draft

Hey Aki,

I was reading through the PUBLISH = draft this morning and noticed something that I think we need to make = some changes to the draft to cover off. Specifically, on page 8, table = 1 shows 4 possible scenarios. However, if you look at this table as a = truth table, the three variables (Body, SIP-If-Match, and Expires =3D = 0) suggests 2^3 results, or 8 results. I believe that these error = scenarios should be explicitly covered off so folks don't think they = can update the state and remove at the same time, while others consider = that to be an error. I think we simply forgot about these scenarios = when going through the draft in earlier prototypes.

Specifically:

  • Contains a body, no SIM, expires = =3D 0: should elicit a 423 because the expires interval on the initial = publish must be non-zero (it makes no sense otherwise).
  • Contains a body, has SIM, expires =3D = 0: should elicit a 423 because modify the state and then immediately = removing it makes no sense (may be controversial).
  • No body, no SIM, expires =3D 0: = should elicit a 412 because there's no way we can match an ETag if none = was supplied as part of the remove operation.
  • No body, no SIM, expires > 0: = should elicit a 400 response because you'd be creating an initial = publication with no state information (makes no sense, but may be = controversial).

Regards,

Brian

------_=_NextPart_001_01C45A1E.0787F2C8-- --===============2027798002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2027798002==-- From simple-bounces@ietf.org Thu Jun 24 19:16:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28003 for ; Thu, 24 Jun 2004 19:14:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddM7-0001ex-Kb for simple-archive@ietf.org; Thu, 24 Jun 2004 19:10:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdcru-0001jA-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 18:38:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdcBI-0000iD-04; Thu, 24 Jun 2004 17:54:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdc5I-0007rf-VU; Thu, 24 Jun 2004 17:48:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbWy-0005ty-IR; Thu, 24 Jun 2004 17:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdaz0-0004zZ-Kh for simple@megatron.ietf.org; Thu, 24 Jun 2004 16:38: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 QAA28378 for ; Thu, 24 Jun 2004 16:38:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdayy-0002Ra-UB for simple@ietf.org; Thu, 24 Jun 2004 16:38:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdaNw-0003Ic-00 for simple@ietf.org; Thu, 24 Jun 2004 15:59:50 -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 1BdZq2-0004Vb-00 for simple@ietf.org; Thu, 24 Jun 2004 15:24:46 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2004 12:27:58 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5OJOB4N028682; Thu, 24 Jun 2004 12:24:12 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJR62555; Thu, 24 Jun 2004 15:24:09 -0400 (EDT) Message-ID: <40DB2A59.2030609@cisco.com> Date: Thu, 24 Jun 2004 15:24:09 -0400 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: Gregg Vanderheiden Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-av References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, paulej@packetizer.com, a.vwijk@viataal.nl, simple@ietf.org, "'Guido Gybels'" , toip@snowshore.com, gunnar.hellstrom@omnitor.se, smundra@telogy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,YOU_WON autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gregg Vanderheiden wrote: > Hi all > > Good conversation. Let me see if I can capture briefly where we all are. > (or might be) > > 1 - IM is not a suitable substitute for interactive text. (char by char) > 2 - IM does have its own uses where it is best > NOTE: There is a fear that some people don't understand 1 and 2 > - but particularly #1 - so they / we worry whenever people use > talk about IM in same sentence with interactive text. > 3 - There is no problem with a client that does both IM and interactive > text I'm with you so far > - as long as interactive text is always available where voice is > available. I think you are dreaming here. Black phones aren't going to support interactive text. Probably lots of phones aren't going to support interactive text. > 4 - Voice with IM alone is not sufficient and is the concern. Its not sufficient for some uses. A lot of people would consider it sufficient, or even excessive. Nevertheless, in the interest of promoting accessibility, it might be practical to argue that any device that supports both Voice *and* IM SHOULD also support real time text. (You can change that to MUST is you can get specific legislation passed that requires it.) The degree of support for both might vary, but for a given device you might expect the degree of support for each to be comparable. (E.g. some devices might only receive IM & RTT, while others might support both send and receive.) > 5 - Since interactive text does not require hardware differences (just > software) from an IM phone / device - both IM and interactive text should be > built into devices from the start (if voice is supported) to provide > conversation capability in text. (Interactive text is also good even where > voice is not supported - but would be beyond equivalence in that case). See above. If the phone doesn't support IM, it probably is a losing battle to get it to support real time text - it either doesn't have necessary UI features, or else it is trying to meet other constraints that conflict with doing this. But there are lots of market pressures that are driving the support of IM in phones. If you can ride that wave to get support of RTT then I think you have won. > Rationale for #5. Some might say that Voice + IM only would be good for > people who were not deaf. And people who are deaf could buy different phones > that are voice +IM + Interactive voice. However, this would mean that > people who are deaf or hard of hearing or who have speech disabilities... > - would have to buy special phones that did not represent the full range > of phones and features that everyone else had. (or companies would have to > create two versions of every phone/device). > - would have to buy them from different locations than regular phones > (special programs) > - would in general not be able to get same price plans and deals > - would not be able to rent phones or use phones supplied with various > programs (unless they also carried a full inventory of both types of > phones). > - and more. > > > > Anyone disagree with any of these? I buy the entire rationale above when it is applied to devices that support Voice + IM rather than to all devices that support voice. > Or are we all on the same page. > If differences - pls post and we can discuss where we differ and why. > Or where we can touch up these points. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 20:05:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03243 for ; Thu, 24 Jun 2004 19:49:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bddk0-0000JK-G4 for simple-archive@ietf.org; Thu, 24 Jun 2004 19:34:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BddYR-0005B0-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 19:22:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BddED-0007YO-00; Thu, 24 Jun 2004 19:01:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdciY-0005db-N4; Thu, 24 Jun 2004 18:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdcYS-0007xT-53 for simple@megatron.ietf.org; Thu, 24 Jun 2004 18:18: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 SAA21089 for ; Thu, 24 Jun 2004 18:18:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdcYQ-000575-MD for simple@ietf.org; Thu, 24 Jun 2004 18:18:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdbqo-0004Ui-00 for simple@ietf.org; Thu, 24 Jun 2004 17:33:43 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BdbE0-0004pf-00 for simple@ietf.org; Thu, 24 Jun 2004 16:53:36 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5OKqqLp018593; Thu, 24 Jun 2004 15:52:53 -0500 From: Robert Sparks To: simple@ietf.org, SIP Implementors Content-Type: text/plain Message-Id: <1088110372.2199.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 24 Jun 2004 15:52:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Looking for XCAP implementations X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks - If you have been or are planning to implement XCAP and think you'll have something working to bring to SIPIT 15 (August 23), please send me a note. If we have enough interest, we'll set aside one of the multiparty test sessions to focus on just this. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 20:05:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03210 for ; Thu, 24 Jun 2004 19:49:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddkF-0000LJ-VO for simple-archive@ietf.org; Thu, 24 Jun 2004 19:35:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BddZ2-0005HO-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 19:23:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BddF3-0000CG-00; Thu, 24 Jun 2004 19:02:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdcil-0005ey-0z; Thu, 24 Jun 2004 18:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdcYq-00089e-6B for simple@megatron.ietf.org; Thu, 24 Jun 2004 18:19: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 SAA21175 for ; Thu, 24 Jun 2004 18:19:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdcYo-0005AV-Nr for simple@ietf.org; Thu, 24 Jun 2004 18:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdbrH-0004ZH-00 for simple@ietf.org; Thu, 24 Jun 2004 17:34:13 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BdbEk-00052X-00 for simple@ietf.org; Thu, 24 Jun 2004 16:54:22 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7107458 for simple@ietf.org; Thu, 24 Jun 2004 16:54:22 -0400 Message-Id: <5.1.0.14.0.20040624164744.024d3480@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 24 Jun 2004 16:54:00 -0400 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] XCAP Issue 8: Etag Scope In-Reply-To: <40DA3EF5.2010001@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think we should stick with option 1. (It happens I had this same debate with a person here at the office last night.) If we tried to define "scopes", we would be defining the outermost layer at which we could provide atomicity. If, when we first defined the application usage, we could be really sure that we knew the right scopes, I suppose we could allow that. However, trying to guess the evolution of information in a structure is difficult. We would probably end up over time with documents with information in strange places so that the lock scope (etag checking) matched the semantic coupling. Unless we are prepared to add additional mandatory headers (a fate I hope to avoid) we have to make sure that the scope that turns out to be necessary is the one that is used. While the "document" may be too large sometimes, too large is not a significant drawback. If the defined scopes are too small, we will find ourselves having to add locking mechanisms. Yours, Joel PS: On the insert issue, I can live with documenting what we have, and I can live with "things are always vacuously present". Adding optional headers is not a good idea. At 10:39 PM 6/23/2004 -0400, Jonathan Rosenberg wrote: >1. Revert to whats currently documented in xcap - there is only one >scope, and its for the entire document. Thus, the document, and all >elements and attributes within it, would have the same etag. This would >make it very hard to have two people independently edit separate parts >of the same document. If you want that, you need to have multiple documents. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 20:07:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03361 for ; Thu, 24 Jun 2004 19:49:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddiZ-0007hX-AE for simple-archive@ietf.org; Thu, 24 Jun 2004 19:33:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BddWa-0004Fq-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 19:20:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BddCU-00073J-00; Thu, 24 Jun 2004 19:00:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdchu-0005MV-R1; Thu, 24 Jun 2004 18:28:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdcTb-0004rt-V9 for simple@megatron.ietf.org; Thu, 24 Jun 2004 18:13: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 SAA19884 for ; Thu, 24 Jun 2004 18:13:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdcTa-0004E7-Dg for simple@ietf.org; Thu, 24 Jun 2004 18:13:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdbif-0002vC-00 for simple@ietf.org; Thu, 24 Jun 2004 17:25:20 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Bdb1w-0002rx-00 for simple@ietf.org; Thu, 24 Jun 2004 16:41:09 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5OKeZm21145; Thu, 24 Jun 2004 16:40:36 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 16:40:36 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710128B315@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , aki.neimi@nokia.com Date: Thu, 24 Jun 2004 16:40:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: simple@ietf.org Subject: [Simple] RE: Comments on PUBLISH Draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1049789583==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1049789583== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45A2B.7E48A9A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45A2B.7E48A9A0 Content-Type: text/plain; charset="ISO-8859-1" Actually, thinking about it some more (and reading a bit more) the No Boyd, no SIM, expires = 0 seems to be more of an invalid initial publish (400 response) than a bad remove (no SIM match eliciting a 412). Regards, Brian -----Original Message----- From: Stucker, Brian [NGC:B621:EXCH] Sent: Thursday, June 24, 2004 2:05 PM To: 'aki.neimi@nokia.com' Cc: 'simple@ietf.org' Subject: Comments on PUBLISH Draft Hey Aki, I was reading through the PUBLISH draft this morning and noticed something that I think we need to make some changes to the draft to cover off. Specifically, on page 8, table 1 shows 4 possible scenarios. However, if you look at this table as a truth table, the three variables (Body, SIP-If-Match, and Expires = 0) suggests 2^3 results, or 8 results. I believe that these error scenarios should be explicitly covered off so folks don't think they can update the state and remove at the same time, while others consider that to be an error. I think we simply forgot about these scenarios when going through the draft in earlier prototypes. Specifically: * Contains a body, no SIM, expires = 0: should elicit a 423 because the expires interval on the initial publish must be non-zero (it makes no sense otherwise). * Contains a body, has SIM, expires = 0: should elicit a 423 because modify the state and then immediately removing it makes no sense (may be controversial). * No body, no SIM, expires = 0: should elicit a 412 because there's no way we can match an ETag if none was supplied as part of the remove operation. * No body, no SIM, expires > 0: should elicit a 400 response because you'd be creating an initial publication with no state information (makes no sense, but may be controversial). Regards, Brian ------_=_NextPart_001_01C45A2B.7E48A9A0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on PUBLISH Draft

Actually, thinking about it some more (and reading a = bit more) the No Boyd, no SIM, expires =3D 0 seems to be more of an = invalid initial publish (400 response) than a bad remove (no SIM match = eliciting a 412).

Regards,

Brian

-----Original Message-----
From: Stucker, Brian [NGC:B621:EXCH]
Sent: Thursday, June 24, 2004 2:05 PM
To: 'aki.neimi@nokia.com'
Cc: 'simple@ietf.org'
Subject: Comments on PUBLISH Draft


Hey Aki,

I was reading through the PUBLISH draft this morning = and noticed something that I think we need to make some changes to the = draft to cover off. Specifically, on page 8, table 1 shows 4 possible = scenarios. However, if you look at this table as a truth table, the = three variables (Body, SIP-If-Match, and Expires =3D 0) suggests 2^3 = results, or 8 results. I believe that these error scenarios should be = explicitly covered off so folks don't think they can update the state = and remove at the same time, while others consider that to be an error. = I think we simply forgot about these scenarios when going through the = draft in earlier prototypes.

Specifically:

*       Contains a = body, no SIM, expires =3D 0: should elicit a 423 because the expires = interval on the initial publish must be non-zero (it makes no sense = otherwise).

*       Contains a = body, has SIM, expires =3D 0: should elicit a 423 because modify the = state and then immediately removing it makes no sense (may be = controversial).

*       No body, no = SIM, expires =3D 0: should elicit a 412 because there's no way we can = match an ETag if none was supplied as part of the remove = operation.

*       No body, no = SIM, expires > 0: should elicit a 400 response because you'd be = creating an initial publication with no state information (makes no = sense, but may be controversial).

Regards,

Brian

------_=_NextPart_001_01C45A2B.7E48A9A0-- --===============1049789583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1049789583==-- From simple-bounces@ietf.org Thu Jun 24 20:34:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08383 for ; Thu, 24 Jun 2004 20:34:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdefN-0004o3-5H for simple-archive@ietf.org; Thu, 24 Jun 2004 20:34:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdedD-0004Aj-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 20:31:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdeaW-0002si-00; Thu, 24 Jun 2004 20:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdeMT-000468-Ly; Thu, 24 Jun 2004 20:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bddxo-0003de-Ck for simple@megatron.ietf.org; Thu, 24 Jun 2004 19: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 TAA02727 for ; Thu, 24 Jun 2004 19:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddnQ-0001II-Rf for simple@ietf.org; Thu, 24 Jun 2004 19:38:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bddex-0006b0-00 for simple@ietf.org; Thu, 24 Jun 2004 19:29:36 -0400 Received: from rrcs-midsouth-24-199-146-6.biz.rr.com ([24.199.146.6] helo=berlin.arid.us ident=system) by ietf-mx with esmtp (Exim 4.12) id 1BddRl-0003IY-00 for simple@ietf.org; Thu, 24 Jun 2004 19:15:57 -0400 Received: from madrid (madrid.arid.us [192.168.1.10]) by berlin.arid.us (8.12.8/8.12.8) with ESMTP id i5ONFkgd020933; Thu, 24 Jun 2004 19:15:46 -0400 Message-Id: <200406242315.i5ONFkgd020933@berlin.arid.us> From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Guido Gybels'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av Date: Thu, 24 Jun 2004 19:15:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-reply-to: <40DAD5E1.4010007@cisco.com> Thread-index: AcRZ7oAhxcB0CC6GT5qLh6XIsdQ+iQAT8qmA Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, a.vwijk@viataal.nl, simple@ietf.org, gv@trace.wisc.edu, toip@snowshore.com, gunnar.hellstrom@omnitor.se, smundra@telogy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul, > I accept your point that IM isn't suitable for a bunch of the > communication needs of the hearing impaired. (Among others.) But I also > want you to accept that RTT isn't a suitable substitute for IM in the > applications that millions (actually probably 10s or 100s of millions) > of people use it everyday. ICQ once had a mode wherein one could send character-at-a-time and it worked pretty well (may still be in there). What was nice about it was that one could begin his/her reply even before the other person finished his/her message. I found the two-way exchange much better than today's IM systems, as there was virtually no delay-- it was real-time. One of the reasons why the IM systems today have problems in scaling is that they have to interface with servers that handle message exchange between all those users you spoke about. The farm of servers to run the existing IM systems do a lot of work and it's not a trivial task. The problem with the model is that farm of central servers that receive and dispatch messages. (Perhaps SIMPLE has done something to improve on the current state of technology, but I'll confess that I don't know.) If we can solve the scalability issues required to handle lots of voice and video streams flowing between users, then it would not take a great leap to do the same thing for text (literally). There may be more text sessions, but the only change in resource requirements from blocks of text and RTT are the resources required to process messages (as there are more RTT packets). For voice, those fifty or so packets per second would not flow through centralized servers and neither should the text. If the system operated allowing media to flow point-to-point, the RTT would scale. I guess the question is whether we will be able to allow audio to flow point-to-point or whether the FWs, NATs, "session border controllers", and such devices will inhibit that. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 22:14:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13726 for ; Thu, 24 Jun 2004 22:14:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdgEp-0000TL-4U for simple-archive@ietf.org; Thu, 24 Jun 2004 22:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdgDu-00009L-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 22:13:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdgDJ-0007bi-00; Thu, 24 Jun 2004 22:13:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdfsK-00022u-R6; Thu, 24 Jun 2004 21:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdfbC-0005hK-RZ for simple@megatron.ietf.org; Thu, 24 Jun 2004 21:33: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 VAA11874 for ; Thu, 24 Jun 2004 21:33:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdfbB-0002J9-49 for simple@ietf.org; Thu, 24 Jun 2004 21:33:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdfaL-0001yu-00 for simple@ietf.org; Thu, 24 Jun 2004 21:32:58 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BdfZd-0001dp-00 for simple@ietf.org; Thu, 24 Jun 2004 21:32:14 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i5P1MnZr015802; Thu, 24 Jun 2004 18:22:50 -0700 (PDT) Received: from [12.47.24.42] (sjc-vpn3-417.cisco.com [10.21.65.161]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQB40155; Thu, 24 Jun 2004 18:22:47 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 24 Jun 2004 18:13:36 -0500 Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was: [avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 From: Cullen Jennings To: Paul H Kyzivat , Gunnar Hellstrom Message-ID: In-Reply-To: <40D97E0D.1030906@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Paul E. Jones'" , "'Arnoud van Wijk'" , simple@ietf.org, Gregg Vanderheiden , "'Toip list'" , "'Mundra, Satish'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit A long time we had a meeting and you said you were interested in a solution that helped people that could not use voice in one or both directions. I said that sounded good and pointed out that the problem was a business case problem not a technical problem. Various people made good arguments that that you need to send it character by character not line by line. You convinced people - thank you. I imagine that people than can use voice will find this useful to for example the same reasons you do. It's good you got this point across. I did not understand this when I first starting talking to people. I get it now. Now, I want to ask yourselves seriously - what is your goal here now. Do you want to get a solution to this that is widely deployed or is their a particular technology you want to push? Do you want the problem solved no matter what the solution or did you just invent the problem to push a particular solution in the first place? MSRP is a protocol that might be able to be a solution. The odds are reasonable that it will be widely deployed. If this happens, the marginal effort to make it meet your requirements would be extremely low and probably you don't need a business case to make it happen. It will get implemented for the fun of it at the same time because it will not take any extra effort. As you point out with T140, it has been standardized for years yet, has it really been very widely implemented? Will it be implemented given the business case that has been presented for it so far. I don't know, maybe, these things take time and effort to catch on, but I find it somewhat doubtful. I would find if very sad to see a group of people who really want to have a solution for this problem to get politically maneuvered into a place where the vendors can say their equipment is fine for section 508 or whatever supercedes it. Yet when the whole systems deploys, for some reason only voice will work but it will not be the fault of any equipment vendor. Be wary of solutions where the phones and GWs will send Voice Band Data packets from which someone else need to extract the data . It will be hard to find the someone else. If you want a solution to the problem, here is my advice: Tell the SIMPLE WG that you have a requirement for character by character text. I have not seen any requirements other than this that MSRP does not already meet. If you want this, now is the time to make sure SIMPLE agrees to do it. This does not stop you from pursuing the ever loved t140 solutions - you can pursue those too. If you want MSRP to be more than what you refer to as IM, now would be a good time to make sure MSRP is right. I'm sure some people will argue that the t140 solutions are less work than MSRP. That may or may not be true but it is irrelevant. I think we need to think about which one is most likely to get implemented. You say IM is not appropriate in all situations, and you want char-by-char on every phone. That sounds good, but think bigger, how about char-by-char on every phone and on every future IM device. There's going to be a lot more of these than phones and every device that has a keyboard is probably going to be an IM device. Go big - make IM work for what you need on everything with a keyboard and on all the phones. A solution that works for both is more likely to happen than one that just works for phones. Cullen PS - I agree with Paul K and Deans comments _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 24 23:17:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17636 for ; Thu, 24 Jun 2004 23:17:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdhDn-000686-DO for simple-archive@ietf.org; Thu, 24 Jun 2004 23:17:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdhCs-0005o1-00 for simple-archive@ietf.org; Thu, 24 Jun 2004 23:16:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdhC4-00059j-00; Thu, 24 Jun 2004 23:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdh40-00086h-On; Thu, 24 Jun 2004 23:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdggK-000308-4N for simple@megatron.ietf.org; Thu, 24 Jun 2004 22: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 WAA16009 for ; Thu, 24 Jun 2004 22:43:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdggH-0002Z4-TI for simple@ietf.org; Thu, 24 Jun 2004 22:43:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdgfY-0002Bx-00 for simple@ietf.org; Thu, 24 Jun 2004 22:42:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Bdgea-0001mA-00 for simple@ietf.org; Thu, 24 Jun 2004 22:41:24 -0400 Received: from panther.cs.columbia.edu (IDENT:qe0omt8SpdKbv+K3DEJ7iqpWhZQzql8b@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5P2fIfq011528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 24 Jun 2004 22:41:18 -0400 (EDT) Received: from [192.168.0.31] (pool-141-153-164-73.mad.east.verizon.net [141.153.164.73]) (authenticated bits=0) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i5P2fHHs024504 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2004 22:41:18 -0400 Message-ID: <40DB90C7.8050700@cs.columbia.edu> Date: Thu, 24 Jun 2004 22:41:11 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] RPID: what does tuple-type really mean? References: <40AB89ED.6080908@nokia.com> <40ABB8A4.4050701@cisco.com> <40AD01C3.9060206@dynamicsoft.com> <40ADC69F.9030609@nokia.com> <40B12899.3070006@dynamicsoft.com> <40B268E0.7060209@cs.columbia.edu> <40B2AEEA.1060801@dynamicsoft.com> <40B2B659.5020007@cs.columbia.edu> <40B42636.2080500@dynamicsoft.com> <40B48C29.5080201@cs.columbia.edu> <40B6886C.5090208@cisco.com> <40B6A050.9040304@cs.columbia.edu> <40BC12AF.8090608@dynamicsoft.com> <40BCCE85.80508@cs.columbia.edu> <40C78CE9.6010507@dynamicsoft.com> <40C960DF.8070702@nokia.com> <40CCFC5A.1040603@cs.columbia.edu> <1087391217.25275.48.camel@esdhcp09nok08188.ntc.nokia.com> In-Reply-To: <1087391217.25275.48.camel@esdhcp09nok08188.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.6.24.105082 X-PerlMx-Spam: Gauge=XI, Probability=11%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: ext Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > So I'd rather define explicitly how overrides should occur, case-by-case > when there is an explicit inheritance relationship to a given element. > And in that sense, it doesn't seem to matter whether the element is > under or under a new element. Can you give an example of where the value for the presentity, whether wrapped around or labeled as such, would not be overridden by a tuple-specific value? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 25 02:55:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12191 for ; Fri, 25 Jun 2004 02:55:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdkcG-0002pI-Ec for simple-archive@ietf.org; Fri, 25 Jun 2004 02:55:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdkbT-0002Rc-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 02:54:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdkaE-0001fz-00; Fri, 25 Jun 2004 02:53:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdkPp-0002Cr-V0; Fri, 25 Jun 2004 02:42:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdkFo-0006sK-Ir for simple@megatron.ietf.org; Fri, 25 Jun 2004 02: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 CAA10257 for ; Fri, 25 Jun 2004 02:32:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdkFm-00028h-Ed for simple@ietf.org; Fri, 25 Jun 2004 02:32:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdkEk-0001kq-00 for simple@ietf.org; Fri, 25 Jun 2004 02:30:59 -0400 Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx with esmtp (Exim 4.12) id 1BdkDj-0000ve-00 for simple@ietf.org; Fri, 25 Jun 2004 02:29:55 -0400 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id BC48637E4F; Fri, 25 Jun 2004 08:29:25 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9B95A37E4F; Fri, 25 Jun 2004 08:29:25 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 56F193800A; Fri, 25 Jun 2004 08:29:25 +0200 (CEST) From: "Gunnar Hellstrom" To: "Cullen Jennings" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Fri, 25 Jun 2004 08:29:23 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-reply-to: Importance: Normal Content-Transfer-Encoding: 7bit Cc: "'Paul E. Jones'" , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cullen, Important factors for real time conversational text are: 1. Wide deployment 2. Good opportunities to combine with voice and video in real time calls 3. Same network traversal opportunities as voice and video. No worse or different NAT and firewall problems than for the other real time media. 4. Meet all the other functional requirements you started with citing. 5. Be careful with tendencies for fragmentation in options and various solutions for the same network type, because that may lead to less interoperability. 6. A scalable solution that survives even to the stage when it is deployed and used in every phone. So, checking MSRP in positive mood, I find: no 2 is likely OK. no 3 is likely not solved today, but if you achieve wide deployment it may become solved. no 4 is probably OK, I am not sure about influence on congestion and network load. MSRP packets seem to get quite long, and we need to transmit every 300 ms to get satisfied users. no 6 is no blocking factor. MSRP can apparently be used peer-to-peer. no 1 is hard to know. Usually it is not the choice of protocol that leads to market success. You indicate that if we made sure that there is a conversational mode for MSRP, we would benefit from a possible success of SIMPLE. I realize the opportunity. no 5 is the most tricky one. If you do text/t140 and I do MSRP/RTT we get no communication. That is the situation we came from, with the fragmented world of seven incompatible protocols for text telephony in PSTN. Now time has come for harmonisation and interoperability in the world of text communication. text/t140 is standardised since year 2000, and included in many documents as the way to go. All what we need is already approved. We are just working with refinements and deployment. So for now the deployment should not be confused by knowing that alternatives may be coming that are in draft stage. If the alternative then comes with proper mechanisms for negotiation in an offer/answer model it may be OK, if it adds very evident value in terms of functionality or deployment opportunities. I see great risks with fragmentation. That is the main threat to proper services. What needs to be done in MSRP? ------------------------------ With that said, we could go into looking at MSRP to see what needs to be done. I found most current specification suitable. We have to define a MIME media type. It could be T.140 text without the RTP packetisation. That is UTF-8 coded Unicode with some usage habit rules. It would be the payload from RFC2793. It should be buffered and sent every 300 ms or so. In section 6.5.3 we have this text: -------------------------------------------------------------- When an endpoint receives a SEND request, it MUST perform the following steps. 1. Check that it has state for a session with a local URL matching the To-Path value. If no matching session exists, return a 481 response. 2. Determine that it understands the media type in the body, if any exists. 3. If it does, return a 200 response and render the message to the user. The method of rendering is a matter of local policy. --------------------------------------------------------------------- It is only this sentence: "The method of rendering is a matter of local policy." that need an addition for the real time case. "The local policy for real time text shall be to display the text from each participant in a separate contigous text display area. Time alignment with text transmitted according to the examples in ITU-T T.140 is RECOMMENDED. Can someone check what bandwidth usage we will cause when using MSRP if we have a rapid typer, typing 9 character per second in English ( causing one byte UTF-8 per character), thus shipping three characters per SEND request? Over the years, T.140 for real time interactive text conversation has been specified to go over: - V.18 modem - T.134 in T.120 data conferencing - H.224 for H.320 ISDN mulitmedia - AL1 for H.324 multimedia opened through H.245 - RFC2793 for H.323 multimedia - TCP for H.323 multimedia - RFC2793 for H.248 gateways - RFC2793 for SIP - RFC2793bis audio/t140c for V.152 gateways So, I am positive to check if it reasonable to add MSRP to the list of transports, provided we do not confuse current deployment activites and we do it in a way that negotiate well with the current SIP RTP solution. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >Of Cullen Jennings >Sent: Friday, June 25, 2004 1:14 AM >To: Paul H Kyzivat; Gunnar Hellstrom >Cc: 'Paul E. Jones'; 'Arnoud van Wijk'; simple@ietf.org; Gregg >Vanderheiden; 'Toip list'; 'Mundra, Satish' >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 >was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > >A long time we had a meeting and you said you were interested in a solution >that helped people that could not use voice in one or both directions. I >said that sounded good and pointed out that the problem was a business case >problem not a technical problem. > >Various people made good arguments that that you need to send it character >by character not line by line. You convinced people - thank you. I imagine >that people than can use voice will find this useful to for example the same >reasons you do. It's good you got this point across. I did not understand >this when I first starting talking to people. I get it now. > >Now, I want to ask yourselves seriously - what is your goal here now. Do you >want to get a solution to this that is widely deployed or is their a >particular technology you want to push? Do you want the problem solved no >matter what the solution or did you just invent the problem to push a >particular solution in the first place? > >MSRP is a protocol that might be able to be a solution. The odds are >reasonable that it will be widely deployed. If this happens, the marginal >effort to make it meet your requirements would be extremely low and probably >you don't need a business case to make it happen. It will get implemented >for the fun of it at the same time because it will not take any extra >effort. > >As you point out with T140, it has been standardized for years yet, has it >really been very widely implemented? Will it be implemented given the >business case that has been presented for it so far. I don't know, maybe, >these things take time and effort to catch on, but I find it somewhat >doubtful. I would find if very sad to see a group of people who really want >to have a solution for this problem to get politically maneuvered into a >place where the vendors can say their equipment is fine for section 508 or >whatever supercedes it. Yet when the whole systems deploys, for some reason >only voice will work but it will not be the fault of any equipment vendor. >Be wary of solutions where the phones and GWs will send Voice Band Data >packets from which someone else need to extract the data . It will be hard >to find the someone else. > >If you want a solution to the problem, here is my advice: Tell the SIMPLE WG >that you have a requirement for character by character text. I have not seen >any requirements other than this that MSRP does not already meet. If you >want this, now is the time to make sure SIMPLE agrees to do it. This does >not stop you from pursuing the ever loved t140 solutions - you can pursue >those too. If you want MSRP to be more than what you refer to as IM, now >would be a good time to make sure MSRP is right. > >I'm sure some people will argue that the t140 solutions are less work than >MSRP. That may or may not be true but it is irrelevant. I think we need to >think about which one is most likely to get implemented. You say IM is not >appropriate in all situations, and you want char-by-char on every phone. >That sounds good, but think bigger, how about char-by-char on every phone >and on every future IM device. There's going to be a lot more of these than >phones and every device that has a keyboard is probably going to be an IM >device. Go big - make IM work for what you need on everything with a >keyboard and on all the phones. A solution that works for both is more >likely to happen than one that just works for phones. > >Cullen > > >PS - I agree with Paul K and Deans comments > > > > > > > > >_______________________________________________ >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-bounces@ietf.org Fri Jun 25 11:38:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12106 for ; Fri, 25 Jun 2004 11:38:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdsmV-0004Rw-9D for simple-archive@ietf.org; Fri, 25 Jun 2004 11:38:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdscb-0002Ro-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 11:28:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdsR7-00006c-01; Fri, 25 Jun 2004 11:16:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdsIi-0005Vu-96; Fri, 25 Jun 2004 11:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrQv-0007di-C7; Fri, 25 Jun 2004 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrN6-0005LC-1K; Fri, 25 Jun 2004 10:08:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01817; Fri, 25 Jun 2004 10:08:01 -0400 (EDT) Message-Id: <200406251408.KAA01817@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 25 Jun 2004 10:08:01 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Manipulating Presence Document Contents Author(s) : M. Isomaki, E. Leppanen Filename : draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt Pages : 11 Date : 2004-6-24 This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is mainly intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs based on which it builds the overall presence state for the presentity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-pidf-manipulation-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-pidf-manipulation-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: <2004-6-25102626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-25102626.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jun 25 11:54:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14782 for ; Fri, 25 Jun 2004 11:54:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdt2X-0000FU-Kf for simple-archive@ietf.org; Fri, 25 Jun 2004 11:54:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdsx2-0006ho-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 11:49:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdssY-0005bP-01; Fri, 25 Jun 2004 11:44:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdslo-0006qx-ST; Fri, 25 Jun 2004 11:37:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdscL-0006k7-LI; Fri, 25 Jun 2004 11:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bds4Z-0000YE-0i for simple@megatron.ietf.org; Fri, 25 Jun 2004 10:52:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06374 for ; Fri, 25 Jun 2004 10:52:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bds4Y-0002uE-AG for simple@ietf.org; Fri, 25 Jun 2004 10:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdrzQ-0001bN-00 for simple@ietf.org; Fri, 25 Jun 2004 10:47:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdrvX-0000V2-00 for simple@ietf.org; Fri, 25 Jun 2004 10:43:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdriu-0003Gk-Pe for simple@ietf.org; Fri, 25 Jun 2004 10:30:36 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2004 07:33:02 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5PEU84N001162; Fri, 25 Jun 2004 07:30:09 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJS13605; Fri, 25 Jun 2004 10:30:06 -0400 (EDT) Message-ID: <40DC36EE.3080206@cisco.com> Date: Fri, 25 Jun 2004 10:30:06 -0400 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: "Paul E. Jones" Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av References: <200406242315.i5ONFkgd020933@berlin.arid.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, "'Guido Gybels'" , a.vwijk@viataal.nl, simple@ietf.org, gv@trace.wisc.edu, toip@snowshore.com, gunnar.hellstrom@omnitor.se, smundra@telogy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul E. Jones wrote: > Paul, > > >>I accept your point that IM isn't suitable for a bunch of the >>communication needs of the hearing impaired. (Among others.) But I also >>want you to accept that RTT isn't a suitable substitute for IM in the >>applications that millions (actually probably 10s or 100s of millions) >>of people use it everyday. > > > ICQ once had a mode wherein one could send character-at-a-time and it worked > pretty well (may still be in there). What was nice about it was that one > could begin his/her reply even before the other person finished his/her > message. I found the two-way exchange much better than today's IM systems, > as there was virtually no delay-- it was real-time. Different strokes for different folks. I personally hate that. > One of the reasons why the IM systems today have problems in scaling is that > they have to interface with servers that handle message exchange between all > those users you spoke about. The farm of servers to run the existing IM > systems do a lot of work and it's not a trivial task. The problem with the > model is that farm of central servers that receive and dispatch messages. > (Perhaps SIMPLE has done something to improve on the current state of > technology, but I'll confess that I don't know.) Well, MSRP is being designed so it can be used point to point. OTOH, it seems that nobody believes it will be used that way in practice. Most people seem to think that network administrators won't want to let IM thru the firewall without logging it. And the explicit support of relays (rather than the hacks involving TURN that are proposed for RTP) is also assumed to be the solution for NATs. So whatever cost their is for having relays is assumed to be a requirement or a feature. > If we can solve the scalability issues required to handle lots of voice and > video streams flowing between users, then it would not take a great leap to > do the same thing for text (literally). But those techniques don't lend themselves to easily monitoring/recording all the media. Because IM is newer and so lacks the legal precedents that voice has, and because the volume (in bits) of IM is substantially less than voice, it is feasible to log it all. (Whether that is a good thing from a social perspective or not.) At least in case of IM to/from enterprises it seems that is the intent. That argues against using an approach where relays are extra burdensome. > There may be more text sessions, > but the only change in resource requirements from blocks of text and RTT are > the resources required to process messages (as there are more RTT packets). I think you may be arguing for RTT as an alternative to MSRP or other message oriented transport of IM. If so, T.140 fails to meet many of the requirements that MSRP has been asked to solve, around confirmation of messages, transmission of material of variouls media types, etc. > For voice, those fifty or so packets per second would not flow through > centralized servers and neither should the text. If the system operated > allowing media to flow point-to-point, the RTT would scale. I guess the > question is whether we will be able to allow audio to flow point-to-point or > whether the FWs, NATs, "session border controllers", and such devices will > inhibit that. STUN is the preferred technique for getting RTP thru nats and firewalls. It does result in e2e flows, and it would work for RTT as well. But IM is a different story. Paul (K) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 25 12:09:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19206 for ; Fri, 25 Jun 2004 12:09:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdtGk-0004oB-VF for simple-archive@ietf.org; Fri, 25 Jun 2004 12:09:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdtG6-0004Tn-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 12:08:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdtEw-00044j-00; Fri, 25 Jun 2004 12:07:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdt1u-00025p-5S; Fri, 25 Jun 2004 11:54:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdsvu-0006M5-FZ for simple@megatron.ietf.org; Fri, 25 Jun 2004 11:48: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 LAA14105 for ; Fri, 25 Jun 2004 11:48:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdsvt-0006V1-Aq for simple@ietf.org; Fri, 25 Jun 2004 11:48:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdsrI-0005Ea-00 for simple@ietf.org; Fri, 25 Jun 2004 11:43:21 -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 1Bdshf-0003M9-00 for simple@ietf.org; Fri, 25 Jun 2004 11:33:23 -0400 Received: from [127.0.0.1] (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i5PFXMpx008549; Fri, 25 Jun 2004 10:33:22 -0500 Message-ID: <40DC45C2.8080506@softarmor.com> Date: Fri, 25 Jun 2004 10:33:22 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar listed out a good set of requirements in RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 I'd like to add one requirement that every Internet protocol should meet, but many (especially early protocols) do not. I'll phrase this as one absolutely critical requirement, and a couple of examples of what this means. I'll admit that the examples have a lot of overlap with each other. Perhaps someone has said this better -- if so, somebody please send me a reference . . . Big Requirement: A user of the Internet must not interfere unfairly with other users of the Internet. What does this mean in design terms? 1) A protocol or suite of protocols supporting an application MUST be both sensitive and reactive to network behavior in real time. 2) A protocol or suite of protocols supporting an application MUST not "flood" network links, stifle or starve other applications, or aggressively try to compensate for network limitations by using more bandwidth. 3) A protocol or suite of protocols supporting an application MUST react to network performance issues in a "fail-safe" manner. If there are problems with the network, this means either "backing off" until the situation gets better, or reporting the conditions up the decision-making tree to an agent with the power to terminate or suspend the application operation until things get better (or possibly, that can make things better by taking actions outside the scope of the application protocol). 4) A protocol or suite of protocols SHOULD be designed in such a way that implementations of applications using that protocol or suite of protocols meet the above requirements "by default", that is, without special effort on the part of the application builder. 5) The best protocols "play nice" by recording network behavior in real time and taking corrective action. This includes things like: a) measuring end-to-end latency, drop rates, jitter, etc. and reducing transmission rates under degraded network conditions, perhaps by changing timing, encoding, buffering, packet size, or flo-control mechanisms. b) Interacting with network nodes to gain additional data about network behavior and using this data to adapt behavior as in A. An example here might be TCP explicit congestion notification (ECN) or frame-relay foward and backward explicit congestion notification (FECN and BECN). What does all this mean to us? Let's thnk about this in the terms of real-time-text and RTP. I'll admit that RTT/RTP can be made to work, even under bad network conditions, but is it a "good citizen" of the internet? Sure, RTCP gives us limited notification capability, and if used carefully in an application could meet most of the fundamental requirement. Problem is, nobody ever does it this way. When was the last time your GTT app popped up and said "I'm observing high loss on this link. Please type slower or give up." This is a failure of #4, above. Developers have to go out of their way to integrate RTCP status with the application and make the application adapt. Many implementors of RTP never get around to doing the RTCP part, and applications quite commonly ignore RTCP even if the stack they're written on supports it. #1 requires that our system sense and react to real network conditions. RTT/RTP as you have outlined it doesn't. Instead, RTT just assumes the network is lossy and congested, and sends things redundantly, obeying its own timers rather than reacting to the ebb and flow of the network beneath it. As a consequence, RTT/RTP violates #2 and #3 as it "out competes" other users by just blasting out redundant transmissions whether they're needed or not. I believe that, if we were designing the protocol today, RTP as it currently exists would not survive the review process. By requiring applications to deal with these complex transport issues, it makes the probability of "well-mannered" implementations quite low. We probably wouldn't use RTP for voice if we had something better-behaved, and we shouldn't use RTP for text when we have the option of using something that's better behaved. Sure, RTP can be made to run with DCCP, and it probably will be some day. But unfortunately, that's probably a few years out before we see any kind of "critical mass", and there'll be a whole new can of firewall/NAT worms to untangle before we can really count on it working in the field. So, what can we do now? Options include: 1) Ignore these problems, because somebody else (perhaps the Bush administration) can be counted on to clean them up for us. 2) If we really need a synchronous real-time end-to-end network, forget about IP and use ATM for real-time text applications. 3) Require RSVP and per-RTT/RTP flow reservations. 4) See how close we can get to meeting our real-time needs with a network-friendly protocol like MSRP. Personally, I prefer option 4, which begs the questions: What exactly do we want for real-time text, what part of it cannot be implemented on a network that is not always a real-time network, and can we get close enough to get something useful out of an MSRP-like protocol? And is the SIMPLE working group willing to tackle this mission? Here's a use case: I'm going to chat with Arnoud. I send him a MESSAGE asking if he wants to talk. Arnoud responds by INVITE-ing me to an MSRP session. We exchange a few slow-text messages. As the conversation warms up, we decide switch to real-time text by clicking the "send in real time" buttons on our texters (which I presume just changes the buffering behavior in MSRP). When we're done, we send BYEs. Throughout the whole conversation, the TCP stacks in our devices were making sure we "played nice" with the other network users. Every now and then, the timing was a bit off, but it was pretty close, and we didn't break anybody's network or interfere unfairly with other applications. That's a good way to use the Internet. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 25 14:05:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29117 for ; Fri, 25 Jun 2004 14:05:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdv4W-0001Am-78 for simple-archive@ietf.org; Fri, 25 Jun 2004 14:05:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdv3a-0000p9-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 14:04:10 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bdv2C-0000Pe-00; Fri, 25 Jun 2004 14:02:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdv2E-0003RI-D7; Fri, 25 Jun 2004 14:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdurj-0005Di-BP; Fri, 25 Jun 2004 13:51:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdukT-0002JS-GD for simple@megatron.ietf.org; Fri, 25 Jun 2004 13:44: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 NAA27474 for ; Fri, 25 Jun 2004 13:44:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdukS-00024J-Gw for simple@ietf.org; Fri, 25 Jun 2004 13:44:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdujY-0001nj-00 for simple@ietf.org; Fri, 25 Jun 2004 13:43:28 -0400 Received: from rrcs-midsouth-24-199-146-6.biz.rr.com ([24.199.146.6] helo=berlin.arid.us ident=system) by ietf-mx with esmtp (Exim 4.12) id 1Bduj8-0001WC-00 for simple@ietf.org; Fri, 25 Jun 2004 13:43:02 -0400 Received: from madrid (madrid.arid.us [192.168.1.10]) by berlin.arid.us (8.12.8/8.12.8) with ESMTP id i5PHgegd024673; Fri, 25 Jun 2004 13:42:40 -0400 Message-Id: <200406251742.i5PHgegd024673@berlin.arid.us> From: "Paul E. Jones" To: "'Arnoud van Wijk'" , "'Paul Kyzivat'" , "'Guido Gybels'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av Date: Fri, 25 Jun 2004 13:42:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-reply-to: <200406251032.i5PAW6dT057499@smtp.eweka.nl> thread-index: AcRZ7oAhxcB0CC6GT5qLh6XIsdQ+iQAT8qmAABaV8PAAEIrC4A== Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, simple@ietf.org, gv@trace.wisc.edu, toip@snowshore.com, gunnar.hellstrom@omnitor.se, smundra@telogy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Arnoud, > Also..I want to point it out again... > WE ARE NOT TALKING ABOUT REPLACING INSTANT MESSAGING WITH INTERACTIVE TEXT! I understand, but I think some opinions expressed is that in order to increase the deployment base, you really need to find a way to marry these two technologies. > And I do hear from many ICQ users who miss the real-time chat mode. That > was > easier to use. And with SIP, server load is not an issue anymore, which > caused ICQ to scrap this option. The reason the server load would have been high would have been because messages were likely not transmitted point-to-point due to firewalls and NATs. SIP does not improve on that. However, other technologies like STUN can help. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 25 14:44:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01865 for ; Fri, 25 Jun 2004 14:44:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdvgj-0005p6-As for simple-archive@ietf.org; Fri, 25 Jun 2004 14:44:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdvfl-0005X7-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 14:43:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bdves-0004xD-00; Fri, 25 Jun 2004 14:42:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdvaR-0003eO-MF; Fri, 25 Jun 2004 14:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdvPM-0000SE-4F for simple@megatron.ietf.org; Fri, 25 Jun 2004 14:26: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 OAA00751 for ; Fri, 25 Jun 2004 14:26:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdvPL-0000Lu-7v for simple@ietf.org; Fri, 25 Jun 2004 14:26:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdvOR-00002t-00 for simple@ietf.org; Fri, 25 Jun 2004 14:25:44 -0400 Received: from rrcs-midsouth-24-199-146-6.biz.rr.com ([24.199.146.6] helo=berlin.arid.us ident=system) by ietf-mx with esmtp (Exim 4.12) id 1BdvNq-0007Xy-00 for simple@ietf.org; Fri, 25 Jun 2004 14:25:06 -0400 Received: from madrid (madrid.arid.us [192.168.1.10]) by berlin.arid.us (8.12.8/8.12.8) with ESMTP id i5PIP0gd024787; Fri, 25 Jun 2004 14:25:00 -0400 Message-Id: <200406251825.i5PIP0gd024787@berlin.arid.us> From: "Paul E. Jones" To: "'Paul Kyzivat'" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av Date: Fri, 25 Jun 2004 14:25:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-reply-to: <40DC36EE.3080206@cisco.com> thread-index: AcRawO9ncF1odzEqRBqdKjjOsGnM5QAHfWdQ Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, "'Guido Gybels'" , a.vwijk@viataal.nl, simple@ietf.org, gv@trace.wisc.edu, toip@snowshore.com, gunnar.hellstrom@omnitor.se, smundra@telogy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul, > But those techniques don't lend themselves to easily > monitoring/recording all the media. Because IM is newer and so lacks the > legal precedents that voice has, and because the volume (in bits) of IM > is substantially less than voice, it is feasible to log it all. (Whether > that is a good thing from a social perspective or not.) At least in case > of IM to/from enterprises it seems that is the intent. That argues > against using an approach where relays are extra burdensome. If somebody is so bent on recording everything coming in and out of his realm of control, then let him buy the horsepower to do it. I do not think that a peer-to-peer model that works like voice and video should be pushed aside for the sake of logging, irrespective of whether "page mode" or "character-at-a-time" mode is used. > I think you may be arguing for RTT as an alternative to MSRP or other > message oriented transport of IM. If so, T.140 fails to meet many of the > requirements that MSRP has been asked to solve, around confirmation of > messages, transmission of material of variouls media types, etc. The loss of characters is detected with RFC 2793, though the sender is not notified that characters are lost necessarily (I suppose this might be gathered from the RTCP stats, but certainly no indication of specific text). I see this as a carry-over from the existing systems. I can see it as useful, but not terribly useful. One should get a BYE message from the SIP session and if there was text in flight as the BYE came across the wire, then the user should suspect it was lost. MSRP definitely has the upper hand on transmitting non-text information, such as pictures and other such things. Perhaps the non-text information could be transported via MSRP and text as RFC 2793. Some devices will not be able to accommodate the non-text information, anyway. While it would result in the RTT mode you don't like, it would also enable interworking between IM systems and legacy TTY devices used by the deaf. The latter cannot operate in "block" mode. > STUN is the preferred technique for getting RTP thru nats and firewalls. > It does result in e2e flows, and it would work for RTT as well. But IM > is a different story. One way... not sure if it is preferred. Wasn't it intended to be a temporary solution from MIDCOM? In any case, I agree that would work in many cases and would be useful for all RTP flows (audio, video, and RFC 2793 text). Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 25 15:09:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03813 for ; Fri, 25 Jun 2004 15:09:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdw4n-0005KS-7a for simple-archive@ietf.org; Fri, 25 Jun 2004 15:09:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdw3n-00051D-00 for simple-archive@ietf.org; Fri, 25 Jun 2004 15:08:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bdw2t-0004SZ-00; Fri, 25 Jun 2004 15:07:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdvur-0002kR-EE; Fri, 25 Jun 2004 14:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdvlO-0007kz-J4 for simple@megatron.ietf.org; Fri, 25 Jun 2004 14:49: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 OAA02228 for ; Fri, 25 Jun 2004 14:49:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdvlN-0007HS-C4 for simple@ietf.org; Fri, 25 Jun 2004 14:49:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdvkM-000705-00 for simple@ietf.org; Fri, 25 Jun 2004 14:48:23 -0400 Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx with esmtp (Exim 4.12) id 1BdvjJ-0006SP-00 for simple@ietf.org; Fri, 25 Jun 2004 14:47:17 -0400 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5344C37FF3; Fri, 25 Jun 2004 20:46:46 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 457C837E53; Fri, 25 Jun 2004 20:46:46 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 11A6F38005; Fri, 25 Jun 2004 20:46:46 +0200 (CEST) From: "Gunnar Hellstrom" To: "Dean Willis" Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Fri, 25 Jun 2004 20:46:42 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-reply-to: <40DC45C2.8080506@softarmor.com> Importance: Normal Content-Transfer-Encoding: 7bit Cc: "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dean, You seem to claim that MSRP for real time text would behave better in congestion than RTP with text/t140. I do not think this can be a decision factor for selecting one of these protocols before the other. RTP for text is not at all causing the continous load as voice and video. Transmission is done just when there is text to transmit, and then we have a default transmission rate of 3 packets per second. In the last edition of rfc2793bis we added a lot of precautions for congestion. But we also added that in case of severe congestion, other streams could be cut out, and the conversation only continue in text in order for the whole conversational application to behave well in the network. Here is the last edition -06: ( - 07 should be out any day now ) http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-06.txt I do not see enough concerns about possibility to combine the text session with simultaneous voice in the discussion. The thoughts about MSRP seems to be too far from the real time media that I would not yet dare to rely on it as a base for real time text during calls. I think we would be better off, having a reference in MSRP saying that when there are real time requirements, a text/t140 RTP stream SHALL be opened and the text conversation performed there instead. Then we can win-win in getting the mass deployment you expect for IM and the real time behaviour that is needed in a more intensive text discussion. Planning for emergency service text handling, for gatewaying to text in other networks etc could continue as now and we would have a smooth transition and big market for future text based services in all time aspects. ------ Did you see my question about what bandwidth an MSRP text session with three payload bytes per packet every 300 ms would generate. That figure is important for judging if the proposal to use MSRP is at all realistic. You who know MSRP can probably tell this easily. ------ Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com] >Sent: Friday, June 25, 2004 5:33 PM >To: Gunnar Hellstrom >Cc: 'Toip list'; simple@ietf.org >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 >was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > >Gunnar listed out a good set of requirements in RE: [Sipping] RE: >text/T140 and audio/t140 was:[avt]Comments/questions on >draft-ietf-avt-rfc2793bis-04 > >I'd like to add one requirement that every Internet protocol should >meet, but many (especially early protocols) do not. > >I'll phrase this as one absolutely critical requirement, and a couple of >examples of what this means. I'll admit that the examples have a lot of >overlap with each other. Perhaps someone has said this better -- if so, >somebody please send me a reference . . . > >Big Requirement: A user of the Internet must not interfere unfairly with >other users of the Internet. > >What does this mean in design terms? > >1) A protocol or suite of protocols supporting an application MUST be >both sensitive and reactive to network behavior in real time. > >2) A protocol or suite of protocols supporting an application MUST not >"flood" network links, stifle or starve other applications, or >aggressively try to compensate for network limitations by using more >bandwidth. > >3) A protocol or suite of protocols supporting an application MUST react >to network performance issues in a "fail-safe" manner. If there are >problems with the network, this means either "backing off" until the >situation gets better, or reporting the conditions up the >decision-making tree to an agent with the power to terminate or suspend >the application operation until things get better (or possibly, that can >make things better by taking actions outside the scope of the >application protocol). > >4) A protocol or suite of protocols SHOULD be designed in such a way >that implementations of applications using that protocol or suite of >protocols meet the above requirements "by default", that is, without >special effort on the part of the application builder. > >5) The best protocols "play nice" by recording network behavior in real >time and taking corrective action. This includes things like: > >a) measuring end-to-end latency, drop rates, jitter, etc. and reducing >transmission rates under degraded network conditions, perhaps by >changing timing, encoding, buffering, packet size, or flo-control >mechanisms. > >b) Interacting with network nodes to gain additional data about network >behavior and using this data to adapt behavior as in A. An example here >might be TCP explicit congestion notification (ECN) or frame-relay >foward and backward explicit congestion notification (FECN and BECN). > >What does all this mean to us? > >Let's thnk about this in the terms of real-time-text and RTP. I'll admit >that RTT/RTP can be made to work, even under bad network conditions, but >is it a "good citizen" of the internet? > >Sure, RTCP gives us limited notification capability, and if used >carefully in an application could meet most of the fundamental >requirement. Problem is, nobody ever does it this way. When was the last >time your GTT app popped up and said "I'm observing high loss on this >link. Please type slower or give up." This is a failure of #4, above. >Developers have to go out of their way to integrate RTCP status with the >application and make the application adapt. Many implementors of RTP >never get around to doing the RTCP part, and applications quite commonly >ignore RTCP even if the stack they're written on supports it. > > >#1 requires that our system sense and react to real network conditions. >RTT/RTP as you have outlined it doesn't. Instead, RTT just assumes the >network is lossy and congested, and sends things redundantly, obeying >its own timers rather than reacting to the ebb and flow of the network >beneath it. As a consequence, RTT/RTP violates #2 and #3 as it "out >competes" other users by just blasting out redundant transmissions >whether they're needed or not. > >I believe that, if we were designing the protocol today, RTP as it >currently exists would not survive the review process. By requiring >applications to deal with these complex transport issues, it makes the >probability of "well-mannered" implementations quite low. We probably >wouldn't use RTP for voice if we had something better-behaved, and we >shouldn't use RTP for text when we have the option of using something >that's better behaved. > >Sure, RTP can be made to run with DCCP, and it probably will be some >day. But unfortunately, that's probably a few years out before we see >any kind of "critical mass", and there'll be a whole new can of >firewall/NAT worms to untangle before we can really count on it working >in the field. > > >So, what can we do now? > >Options include: > >1) Ignore these problems, because somebody else (perhaps the Bush >administration) can be counted on to clean them up for us. > >2) If we really need a synchronous real-time end-to-end network, forget >about IP and use ATM for real-time text applications. > >3) Require RSVP and per-RTT/RTP flow reservations. > >4) See how close we can get to meeting our real-time needs with a >network-friendly protocol like MSRP. > > >Personally, I prefer option 4, which begs the questions: > >What exactly do we want for real-time text, what part of it cannot be >implemented on a network that is not always a real-time network, and can >we get close enough to get something useful out of an MSRP-like >protocol? And is the SIMPLE working group willing to tackle this mission? > > > >Here's a use case: > >I'm going to chat with Arnoud. I send him a MESSAGE asking if he wants >to talk. Arnoud responds by INVITE-ing me to an MSRP session. We >exchange a few slow-text messages. As the conversation warms up, we >decide switch to real-time text by clicking the "send in real time" >buttons on our texters (which I presume just changes the buffering >behavior in MSRP). When we're done, we send BYEs. Throughout the whole >conversation, the TCP stacks in our devices were making sure we "played >nice" with the other network users. Every now and then, the timing was a >bit off, but it was pretty close, and we didn't break anybody's network >or interfere unfairly with other applications. That's a good way to use >the Internet. > > >-- >Dean > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 03:53:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27013 for ; Sat, 26 Jun 2004 03:53:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Be80V-0001Er-Ud for simple-archive@ietf.org; Sat, 26 Jun 2004 03:53:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be7zY-0000yr-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 03:52:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Be7yg-0000To-00; Sat, 26 Jun 2004 03:51:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be7tb-0000mA-TV; Sat, 26 Jun 2004 03:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be7n1-0007sV-R9 for simple@megatron.ietf.org; Sat, 26 Jun 2004 03:39: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 DAA26696 for ; Sat, 26 Jun 2004 03:39:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Be7mw-0005RM-Ul for simple@ietf.org; Sat, 26 Jun 2004 03:39:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be7m0-0005Bo-00 for simple@ietf.org; Sat, 26 Jun 2004 03:38:52 -0400 Received: from av2-1-sn3.vrr.skanova.net ([81.228.9.107]) by ietf-mx with esmtp (Exim 4.12) id 1Be7lW-0004vX-00 for simple@ietf.org; Sat, 26 Jun 2004 03:38:23 -0400 Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id A51DC38096; Sat, 26 Jun 2004 09:37:50 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 96A343808D; Sat, 26 Jun 2004 09:37:50 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 7046138009; Sat, 26 Jun 2004 09:37:50 +0200 (CEST) From: "Gunnar Hellstrom" To: "STF267" , "SIMPLE" , "Toip list" Date: Sat, 26 Jun 2004 09:37:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] Using MSRP for real time text conversation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This is a continuation of the discussion about the feasability of using s= imple:s instant messaging protocol MSRP for real time text conversation. (The discussion was held under the subject: "RE: [Simple] RE: [Sipping] R= E: text/T140 and audio/t140was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04". I= thought it was time to make it more clear what the real subject is.) One factor for checking the feasibility of using MSRP for real time text = conversation is the bandwidth it creates. We have just had a discussion about the real time requirements for the re= al time experience of a text conversation. We have an old recommended figure sayi= ng that we should ship session conencts at least every 300 ms. This is confirmed to give a = good real time experience. Some voices have been for transmission more often, but I thin= k they are not based on real experienced needs. Transmission less often creates an unple= asant chunkiness in the perception of the dialogue. So, for now, let us assume that transmission in 300 ms intervals is used = (when there is new text available for transmission ). I made a calculation of a normal MSRP based text conversation exchange wi= th material from the MSRP specification. This is the packet that needs to be sent for theree characters of text fr= om the session: ------------------Lower level headers - do not bother to calculate here---------------------- --------------------------IP V4 header 20 bytes ----- ----------------------------TCP header 24 bytes ----- ----------------------------MRSP SEND -189 bytes-including 3 bytes payload-------------------- MSRP SEND Boundary: d93kswow To-Path:msrp://bob.atlanta.com:8888/9di4ea From-Path:msrp://alicepc.atlanta.com:7777/iau39 TR-ID: 123 Message-ID: 123 Content-Type: "text/t140p" Hi, -------d93kswow+ --------------------------------End of SEND request----------- So, it sums up to 233 bytes transmission =3D 1864 bits. In order to get the real time experience we should allow 3.3 packets per = second. That makes 6150 bits/second. The return direction will have approximately the same load by the 200 OK = and the TCP acknowledgements. So, we would need approximately 6 kbit/s both ways for this text session.= Most of it is overhead, so it does not change much if we use the highest typing speed w= e design for, that is 30 characters per second and type in Korean that will require 3 b= ytes UTF-8 per character. Using RTP, with text/t140 and two generations of redundancy that give goo= d reliability, consumes around 2 kbit/s in the same situation. 6 kbit/s is a bit high load, but I would say that it is not totally out o= f scope. What do you think? Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 07:50:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04231 for ; Sat, 26 Jun 2004 07:49:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeBh2-0006Bn-A9 for simple-archive@ietf.org; Sat, 26 Jun 2004 07:50:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeBg3-0005vg-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 07:49:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeBf7-0005QG-00; Sat, 26 Jun 2004 07:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeBZg-0006Hp-LJ; Sat, 26 Jun 2004 07:42:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeBUc-0004PE-2S for simple@megatron.ietf.org; Sat, 26 Jun 2004 07:37: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 HAA03741 for ; Sat, 26 Jun 2004 07:37:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeBUb-0002qM-A6 for simple@ietf.org; Sat, 26 Jun 2004 07:37:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeBTe-0002aS-00 for simple@ietf.org; Sat, 26 Jun 2004 07:36:11 -0400 Received: from av5-1-sn1.fre.skanova.net ([81.228.11.111]) by ietf-mx with esmtp (Exim 4.12) id 1BeBT6-0002Jr-00 for simple@ietf.org; Sat, 26 Jun 2004 07:35:36 -0400 Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id 7EE6737EF5; Sat, 26 Jun 2004 13:35:04 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 7081C37EF3; Sat, 26 Jun 2004 13:35:04 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 0228037E42; Sat, 26 Jun 2004 13:35:03 +0200 (CEST) From: "Gunnar Hellstrom" To: "A vWijk" , , , Date: Sat, 26 Jun 2004 13:35:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Betr.: Using MSRP for real time text conversation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Arnoud, I agree that the best opportunity to widespread implementation and intero= perability is to have one good standardised method for real time text conversation per net= work type. We have just avoided (?) the threat for fragmentation even on the RTP sid= e by carefully specifying the application areas and priorities for the two variants text= /t140 and audio/t140c. Why do I then immediately accept to enter a discussion of another option = for the same function in the same network? I thought the invitation was an interesting challenge, worth evaluating. = "Come use MRSP and you will reach mass deployment for real time text conversation". Entering the discussion does not mean that I have accepted that it is a g= ood idea to standardise the MRSP option. So far, it seems to me that going with VoIP and IP Multimedia conversatio= n is the more logical route to keep on. The bandwidth requirements for MSRP was not enc= ouraging. The NAT traversal functions are less developed than for SIP with RTP. But let us continue the feasability study a bit further. I would also lik= e to hear the voice of some industries if it really matters what base protocol that is = used for getting deployed in a majority of IP terminals and supported by network component= s? Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: A vWijk [mailto:A.vWijk@viataal.nl] >Sent: Saturday, June 26, 2004 11:39 AM >To: stf267@etsi.org; simple@ietf.org; gunnar.hellstrom@omnitor.se; >toip@snowshore.com >Subject: Betr.: Using MSRP for real time text conversation > > >Gunnar thank you for the explanation. >Now, my question is..why do we need to do this? > >Can we not just stick to t140/RTP and focus on making the interface and = the >handling of the IM so that a user can easily switch between Interactive = text and >Instant messaging? > >Because, any device that will support IM using SIMPLE's MSRP will also u= se VoIP. >Thus will support RTP. > >I am NOT happy to add yet another way of transporting t140. And even cau= sing 3 >times as much bandwidth. > > >The more alternatives you offer to transport t140, the bigger the chance= is that >several t140 devices cannot interwork with each other! >And then we end up again with the mess that there are 7 different analog= ue text >telephone protocols! > >That are my 2 cents here. > >greetz > >Arnoud > > ><<< "Gunnar Hellstrom" 26-06 10:27 >>> >This is a continuation of the discussion about the feasability of using = simple:s instant >messaging protocol MSRP for real time text conversation. > >(The discussion was held under the subject: "RE: [Simple] RE: [Sipping] = RE: text/T140 and >audio/t140was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04". = I thought it was >time to make it more clear what the real subject is.) > >One factor for checking the feasibility of using MSRP for real time text= conversation is >the bandwidth it creates. > >We have just had a discussion about the real time requirements for the r= eal time >experience of a text conversation. We have an old recommended figure say= ing that >we should >ship session conencts at least every 300 ms. This is confirmed to give a= good real time >experience. Some voices have been for transmission more often, but I thi= nk they are not >based on real experienced needs. Transmission less often creates an unpl= easant chunkiness >in the perception of the dialogue. > >So, for now, let us assume that transmission in 300 ms intervals is used= (when there is >new text available for transmission ). > >I made a calculation of a normal MSRP based text conversation exchange w= ith material from >the MSRP specification. > >This is the packet that needs to be sent for theree characters of text f= rom the session: >------------------Lower level headers - do not bother to calculate >here---------------------- >--------------------------IP V4 header 20 bytes ----- >----------------------------TCP header 24 bytes ----- >----------------------------MRSP SEND -189 bytes-including 3 bytes >payload-------------------- >MSRP SEND >Boundary: d93kswow >To-Path:msrp://bob.atlanta.com:8888/9di4ea >From-Path:msrp://alicepc.atlanta.com:7777/iau39 >TR-ID: 123 >Message-ID: 123 >Content-Type: "text/t140p" >Hi, >-------d93kswow+ >--------------------------------End of SEND request----------- > >So, it sums up to 233 bytes transmission =3D 1864 bits. > >In order to get the real time experience we should allow 3.3 packets per= second. That >makes 6150 bits/second. > > >The return direction will have approximately the same load by the 200 OK= and the TCP >acknowledgements. > > >So, we would need approximately 6 kbit/s both ways for this text session= . Most of it is >overhead, so it does not change much if we use the highest typing speed = we design for, >that is 30 characters per second and type in Korean that will require 3 = bytes UTF-8 per >character. > > >Using RTP, with text/t140 and two generations of redundancy that give go= od reliability, >consumes around 2 kbit/s in the same situation. > >6 kbit/s is a bit high load, but I would say that it is not totally out = of scope. > >What do you think? > >Gunnar >------------------------------------------- >Gunnar Hellstr=F6m >Omnitor AB >Renathv=E4gen 2 >SE 121 37 Johanneshov >SWEDEN >+46 8 556 002 03 >Mob: +46 708 204 288 >www.omnitor.se >Gunnar.Hellstrom@Omnitor.se >-------------------------------------------- > > > >- >This list is maintained by Snowshore Networks - http://www.snowshore.com >All comments on this list a > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 10:51:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12099 for ; Sat, 26 Jun 2004 10:51:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeEWQ-0004F7-Pp for simple-archive@ietf.org; Sat, 26 Jun 2004 10:51:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeEVb-0003zz-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 10:50:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeEUg-0003Tq-00; Sat, 26 Jun 2004 10:49:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeERZ-0003ge-O5; Sat, 26 Jun 2004 10:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeEPX-00034m-MA for simple@megatron.ietf.org; Sat, 26 Jun 2004 10: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 KAA11387 for ; Sat, 26 Jun 2004 10:44:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeEPW-0002CQ-P3 for simple@ietf.org; Sat, 26 Jun 2004 10:44:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeEOX-0001vQ-00 for simple@ietf.org; Sat, 26 Jun 2004 10:43:06 -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 1BeENV-0001SP-00 for simple@ietf.org; Sat, 26 Jun 2004 10:42:01 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2004 07:45:35 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5QEfSgI002470; Sat, 26 Jun 2004 07:41:29 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn3-685.cisco.com [10.21.66.173]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQC40512; Sat, 26 Jun 2004 07:41:26 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 26 Jun 2004 07:26:18 -0700 Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 From: Cullen Jennings To: Gunnar Hellstrom Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Paul E. Jones'" , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thank you that is exactly the type of email I was hoping for - we can figure out it is a possibility or not. As a very rough cut on some bandwidth estimates for the 1 message every 300 ms with 3 characters. An example message from the MSRP draft with 3 characters was about 194 bytes resulting in approximately 6 Kbps rate. Seems like this will probably be less than voice but is still concerning. The wireless people clearly want to keep the size of this message down too so it will be interesting to see how the protocols comes out. I suspect the NAT issues are not that big a deal. For the audio call to work at all, both signaling and RTP needed to work and where that is possible it is probably possible to make any of the solutions work from a NAT traversal point of view. Ditto for any logging/RAVEN/CALEA type things. The scale issues are less concerning for me. Odds are that a small percentage of the overall IM or voice traffic would be involved in this type of messaging make the total impact minimal on things other than the endpoints and GWs. A silly question about the mime type. Could text/plain work? I get your point that having both t140 and MSRP may be worse than just t140 but not sure if I agree or not - it's a very hard one to know. I imagine that in the end, figuring out this one largely determines what we should do here. Cullen On 6/24/04 11:29 PM, "Gunnar Hellstrom" wrote: > Cullen, > > Important factors for real time conversational text are: > > 1. Wide deployment > 2. Good opportunities to combine with voice and video in real time calls > 3. Same network traversal opportunities as voice and video. No worse or > different NAT and > firewall problems than for the other real time media. > 4. Meet all the other functional requirements you started with citing. > 5. Be careful with tendencies for fragmentation in options and various > solutions for the > same network type, because that may lead to less interoperability. > 6. A scalable solution that survives even to the stage when it is deployed and > used in > every phone. > > So, checking MSRP in positive mood, I find: > > no 2 is likely OK. > no 3 is likely not solved today, but if you achieve wide deployment it may > become solved. > no 4 is probably OK, I am not sure about influence on congestion and network > load. MSRP > packets seem to get quite long, and we need to transmit every 300 ms to get > satisfied > users. > no 6 is no blocking factor. MSRP can apparently be used peer-to-peer. > no 1 is hard to know. Usually it is not the choice of protocol that leads to > market > success. You indicate that if we made sure that there is a conversational mode > for MSRP, > we would benefit from a possible success of SIMPLE. I realize the opportunity. > > no 5 is the most tricky one. If you do text/t140 and I do MSRP/RTT we get no > communication. That is the situation we came from, with the fragmented world > of seven > incompatible protocols for text telephony in PSTN. Now time has come for > harmonisation and > interoperability in the world of text communication. > text/t140 is standardised since year 2000, and included in many documents as > the way to > go. All what we need is already approved. We are just working with refinements > and > deployment. So for now the deployment should not be confused by knowing that > alternatives > may be coming that are in draft stage. If the alternative then comes with > proper > mechanisms for negotiation in an offer/answer model it may be OK, if it adds > very evident > value in terms of functionality or deployment opportunities. I see great risks > with > fragmentation. That is the main threat to proper services. > > What needs to be done in MSRP? > ------------------------------ > With that said, we could go into looking at MSRP to see what needs to be done. > > I found most current specification suitable. > > We have to define a MIME media type. It could be T.140 text without the RTP > packetisation. > That is UTF-8 coded Unicode with some usage habit rules. It would be the > payload from > RFC2793. > > It should be buffered and sent every 300 ms or so. > > > In section 6.5.3 we have this text: > -------------------------------------------------------------- > When an endpoint receives a SEND request, it MUST perform the > following steps. > > 1. Check that it has state for a session with a local URL matching > the To-Path value. If no matching session exists, return a 481 > response. > > 2. Determine that it understands the media type in the body, if any > exists. > > 3. If it does, return a 200 response and render the message to the > user. The method of rendering is a matter of local policy. > --------------------------------------------------------------------- > It is only this sentence: "The method of rendering is a matter of local > policy." that need > an addition for the real time case. > "The local policy for real time text shall be to display the text from each > participant in > a separate contigous text display area. Time alignment with text transmitted > according to > the examples in ITU-T T.140 is RECOMMENDED. > > Can someone check what bandwidth usage we will cause when using MSRP if we > have a rapid > typer, typing 9 character per second in English ( causing one byte UTF-8 per > character), > thus shipping three characters per SEND request? > > > Over the years, T.140 for real time interactive text conversation has been > specified to go > over: > - V.18 modem > - T.134 in T.120 data conferencing > - H.224 for H.320 ISDN mulitmedia > - AL1 for H.324 multimedia opened through H.245 > - RFC2793 for H.323 multimedia > - TCP for H.323 multimedia > - RFC2793 for H.248 gateways > - RFC2793 for SIP > - RFC2793bis audio/t140c for V.152 gateways > > So, I am positive to check if it reasonable to add MSRP to the list of > transports, > provided we do not confuse current deployment activites and we do it in a way > that > negotiate well with the current SIP RTP solution. > > Gunnar > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 13:22:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19556 for ; Sat, 26 Jun 2004 13:22:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeGsk-0001pg-2o for simple-archive@ietf.org; Sat, 26 Jun 2004 13:22:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeGrv-0001ab-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 13:21:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeGrA-0001ID-00; Sat, 26 Jun 2004 13:20:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeGbB-0001pc-18; Sat, 26 Jun 2004 13:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeGMY-0006JM-3H for simple@megatron.ietf.org; Sat, 26 Jun 2004 12:49: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 MAA17999 for ; Sat, 26 Jun 2004 12:49:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeGMW-0001E6-Tf for simple@ietf.org; Sat, 26 Jun 2004 12:49:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeGJu-0000cY-00 for simple@ietf.org; Sat, 26 Jun 2004 12:46:27 -0400 Received: from av9-1-sn1.fre.skanova.net ([81.228.11.115]) by ietf-mx with esmtp (Exim 4.12) id 1BeGFx-0007Do-00 for simple@ietf.org; Sat, 26 Jun 2004 12:42:21 -0400 Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id CCC9037E95; Sat, 26 Jun 2004 18:41:49 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id BD5B137E67; Sat, 26 Jun 2004 18:41:49 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 81AA037E46; Sat, 26 Jun 2004 18:41:49 +0200 (CEST) From: "Gunnar Hellstrom" To: "Cullen Jennings" Subject: [Simple] RE: Betr.: Using MSRP for real time text conversation Date: Sat, 26 Jun 2004 18:41:47 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Cc: STF267 , "'Paul E. Jones'" , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Culllen, You ask: "A silly question about the mime type. Could text/plain work?" No, All these various 7 and 8 bit character sets have caused enough confusion in the world and should be abandonned. Only Unicode is usable without confusion. To open for a subparameter of text/plain specifying a character set, and having US-ASCII as the default is not suitable in modern communication. I hope you do not intend to use this coding in other parts of simple! There are eternal mistakes when these character sets are missing, or applications try to translate between them. The national characters get destroyed or even whole character sets get non displayable. More specifically, you have to set limits to what editing you can allow during a real time conversational session. And you may want to add some specified rendering effects. That is what you get by specifying ITU-T T.140 instead of just saying UNICODE. There has been some mentioning about T.140 as a transmission mechanism, but that is not what it is. It is a simple set of rules around How to use Unicode in a real time conversation. We should look at this with open minds, but it is likely that we end up with something approximately like T.140 for the text coding. Let us see. Editing: In a real time conversation you need to allow some "remote editing". The only reliable way is to allow erasure of the last character for correction. A number of characters back must be guarnateed to be stored in a buffer so that erasing into it can be done. Insertion of new line is also needed. Allowing other forms of cursor positioning with effects on the remote side is risky because the layout must be allowed to be completely different. Therefore other cursor controls are not included in T.140. Rendering: There might be some interest in adding colour to the text or other rendering effects. This is allowed in T.140, by using such codes from ISO 6429, but I do not know any implementations supportning them. When you are in a real time text conversation, you tend to concentrate on the typing text and ignore such effects. It is important to remember that there are many varied writing directions in the world, so that it must be possible to display text with writing direction right to left etc. Using T.140 would make it easy to arrange gateways to other forms of text conversation. I have not heard anyone lacking any functions in T.140. Negotiating the real time mode: There must be a way to tell both sides that we now enter a real time text session. That should then cause transmission characteristics go real time, and reception and display to change to adding incoming text to a contigous field for incoming text and be prepared to do the edits. I did not see any extra field for indication of modes duing the session, so a new mime subtype could be used as the way to signal to the applications to enter the real time mode. Already in the SIP session setup it must be possible to see that the session is offered in order to handle real time text, so that both sides can select a common method. So, the current offering in MSRP with just m=message is not sufficient. It must also be planned to be possible to specify preferences and callee capablilities for text. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Saturday, June 26, 2004 4:26 PM >To: Gunnar Hellstrom >Cc: 'Paul E. Jones'; 'Toip list'; simple@ietf.org >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and >audio/t140was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > >Thank you that is exactly the type of email I was hoping for - we can figure >out it is a possibility or not. > >As a very rough cut on some bandwidth estimates for the 1 message every 300 >ms with 3 characters. An example message from the MSRP draft with 3 >characters was about 194 bytes resulting in approximately 6 Kbps rate. Seems >like this will probably be less than voice but is still concerning. The >wireless people clearly want to keep the size of this message down too so it >will be interesting to see how the protocols comes out. > >I suspect the NAT issues are not that big a deal. For the audio call to work >at all, both signaling and RTP needed to work and where that is possible it >is probably possible to make any of the solutions work from a NAT traversal >point of view. Ditto for any logging/RAVEN/CALEA type things. > >The scale issues are less concerning for me. Odds are that a small >percentage of the overall IM or voice traffic would be involved in this type >of messaging make the total impact minimal on things other than the >endpoints and GWs. > >A silly question about the mime type. Could text/plain work? > >I get your point that having both t140 and MSRP may be worse than just t140 >but not sure if I agree or not - it's a very hard one to know. I imagine >that in the end, figuring out this one largely determines what we should do >here. > >Cullen > > >On 6/24/04 11:29 PM, "Gunnar Hellstrom" wrote: > >> Cullen, >> >> Important factors for real time conversational text are: >> >> 1. Wide deployment >> 2. Good opportunities to combine with voice and video in real time calls >> 3. Same network traversal opportunities as voice and video. No worse or >> different NAT and >> firewall problems than for the other real time media. >> 4. Meet all the other functional requirements you started with citing. >> 5. Be careful with tendencies for fragmentation in options and various >> solutions for the >> same network type, because that may lead to less interoperability. >> 6. A scalable solution that survives even to the stage when it is deployed and >> used in >> every phone. >> >> So, checking MSRP in positive mood, I find: >> >> no 2 is likely OK. >> no 3 is likely not solved today, but if you achieve wide deployment it may >> become solved. >> no 4 is probably OK, I am not sure about influence on congestion and network >> load. MSRP >> packets seem to get quite long, and we need to transmit every 300 ms to get >> satisfied >> users. >> no 6 is no blocking factor. MSRP can apparently be used peer-to-peer. >> no 1 is hard to know. Usually it is not the choice of protocol that leads to >> market >> success. You indicate that if we made sure that there is a conversational mode >> for MSRP, >> we would benefit from a possible success of SIMPLE. I realize the opportunity. >> >> no 5 is the most tricky one. If you do text/t140 and I do MSRP/RTT we get no >> communication. That is the situation we came from, with the fragmented world >> of seven >> incompatible protocols for text telephony in PSTN. Now time has come for >> harmonisation and >> interoperability in the world of text communication. >> text/t140 is standardised since year 2000, and included in many documents as >> the way to >> go. All what we need is already approved. We are just working with refinements >> and >> deployment. So for now the deployment should not be confused by knowing that >> alternatives >> may be coming that are in draft stage. If the alternative then comes with >> proper >> mechanisms for negotiation in an offer/answer model it may be OK, if it adds >> very evident >> value in terms of functionality or deployment opportunities. I see great risks >> with >> fragmentation. That is the main threat to proper services. >> >> What needs to be done in MSRP? >> ------------------------------ >> With that said, we could go into looking at MSRP to see what needs to be done. >> >> I found most current specification suitable. >> >> We have to define a MIME media type. It could be T.140 text without the RTP >> packetisation. >> That is UTF-8 coded Unicode with some usage habit rules. It would be the >> payload from >> RFC2793. >> >> It should be buffered and sent every 300 ms or so. >> >> >> In section 6.5.3 we have this text: >> -------------------------------------------------------------- >> When an endpoint receives a SEND request, it MUST perform the >> following steps. >> >> 1. Check that it has state for a session with a local URL matching >> the To-Path value. If no matching session exists, return a 481 >> response. >> >> 2. Determine that it understands the media type in the body, if any >> exists. >> >> 3. If it does, return a 200 response and render the message to the >> user. The method of rendering is a matter of local policy. >> --------------------------------------------------------------------- >> It is only this sentence: "The method of rendering is a matter of local >> policy." that need >> an addition for the real time case. >> "The local policy for real time text shall be to display the text from each >> participant in >> a separate contigous text display area. Time alignment with text transmitted >> according to >> the examples in ITU-T T.140 is RECOMMENDED. >> >> Can someone check what bandwidth usage we will cause when using MSRP if we >> have a rapid >> typer, typing 9 character per second in English ( causing one byte UTF-8 per >> character), >> thus shipping three characters per SEND request? >> >> >> Over the years, T.140 for real time interactive text conversation has been >> specified to go >> over: >> - V.18 modem >> - T.134 in T.120 data conferencing >> - H.224 for H.320 ISDN mulitmedia >> - AL1 for H.324 multimedia opened through H.245 >> - RFC2793 for H.323 multimedia >> - TCP for H.323 multimedia >> - RFC2793 for H.248 gateways >> - RFC2793 for SIP >> - RFC2793bis audio/t140c for V.152 gateways >> >> So, I am positive to check if it reasonable to add MSRP to the list of >> transports, >> provided we do not confuse current deployment activites and we do it in a way >> that >> negotiate well with the current SIP RTP solution. >> >> Gunnar >> ------------------------------------------- >> Gunnar Hellstrom >> Omnitor AB >> Renathvagen 2 >> SE 121 37 Johanneshov >> SWEDEN >> +46 8 556 002 03 >> Mob: +46 708 204 288 >> www.omnitor.se >> Gunnar.Hellstrom@Omnitor.se >> -------------------------------------------- >> >> > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 16:04:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26811 for ; Sat, 26 Jun 2004 16:04:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeJPy-00027A-Se for simple-archive@ietf.org; Sat, 26 Jun 2004 16:04:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeJOx-0001mz-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 16:03:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeJO5-0001OZ-00; Sat, 26 Jun 2004 16:02:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeJBj-00070h-HD; Sat, 26 Jun 2004 15:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeJ91-0006DG-18 for simple@megatron.ietf.org; Sat, 26 Jun 2004 15:47: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 PAA25561 for ; Sat, 26 Jun 2004 15:47:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeJ8z-000516-TR for simple@ietf.org; Sat, 26 Jun 2004 15:47:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeJ80-0004mW-00 for simple@ietf.org; Sat, 26 Jun 2004 15:46:21 -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 1BeJ75-0004LA-00 for simple@ietf.org; Sat, 26 Jun 2004 15:45:23 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2004 12:47:58 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5QJiqgI007608; Sat, 26 Jun 2004 12:44:52 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn4-438.cisco.com [10.21.81.182]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQC46875; Sat, 26 Jun 2004 12:44:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 26 Jun 2004 12:44:07 -0700 Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text conversation From: Cullen Jennings To: Gunnar Hellstrom Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: STF267 , "'Paul E. Jones'" , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On 6/26/04 9:41 AM, "Gunnar Hellstrom" wrote: > Negotiating the real time mode: > There must be a way to tell both sides that we now enter a real time text > session. That > should then cause transmission characteristics go real time, and reception and > display to > change to adding incoming text to a contigous field for incoming text and be > prepared to > do the edits. Indeed - I was thinking that the senders application could allow them to select their preference for what they were sending and indicate in the arriving data that it was character by character mode so the receive could display and edit appropriately. Somewhat interesting questions about getting out of this mode. I was sort of wondering what the 2973bis draft was going to say about getting and INT sequence in the T.140 packets. It seemed strangely silent on this. It might be somewhat difficult to deal with given it is mixing signaling into a media stream. I'm particularly interested to see the security considerations for this. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 16:04:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26834 for ; Sat, 26 Jun 2004 16:04:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeJQ0-00027L-GJ for simple-archive@ietf.org; Sat, 26 Jun 2004 16:04:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeJOy-0001nE-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 16:03:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeJO5-0001Oa-00; Sat, 26 Jun 2004 16:02:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeJBj-00070c-2U; Sat, 26 Jun 2004 15:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeJ8z-0006DF-LI for simple@megatron.ietf.org; Sat, 26 Jun 2004 15:47: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 PAA25551 for ; Sat, 26 Jun 2004 15:47:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeJ8y-00050w-I9 for simple@ietf.org; Sat, 26 Jun 2004 15:47:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeJ7z-0004mG-00 for simple@ietf.org; Sat, 26 Jun 2004 15:46:19 -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 1BeJ74-0004LA-00 for simple@ietf.org; Sat, 26 Jun 2004 15:45:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2004 12:47:55 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5QJiogI007602; Sat, 26 Jun 2004 12:44:50 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn4-438.cisco.com [10.21.81.182]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQC46874; Sat, 26 Jun 2004 12:44:49 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 26 Jun 2004 12:43:55 -0700 Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text conversation From: Cullen Jennings To: Gunnar Hellstrom Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: STF267 , "'Paul E. Jones'" , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On 6/26/04 9:41 AM, "Gunnar Hellstrom" wrote: > Culllen, > > You ask: > "A silly question about the mime type. Could text/plain work?" > > No, > All these various 7 and 8 bit character sets have caused enough confusion in > the world and > should be abandonned. Only Unicode is usable without confusion. > To open for a subparameter of text/plain specifying a character set, and > having US-ASCII > as the default is not suitable in modern communication. I hope you do not > intend to use > this coding in other parts of simple! My assumption is that the charset would be utf-8 - I understand that us-ascii is the default for text/plain but it seems unlikely that we would not mandate utf-8. > > And you may want to add some specified rendering effects. > Hmm, I suspect that is true that IM will want that - including HTML, RTF, and Emoticon stuff. The richness of existing IM clients with respect to this is one of the advantages of it. I have to admit my recollection of T.140 is a bit vague - What rendering effects does it support? I seem to recall some Select graphic Renditions stuff that did not seem of much use but I forget. What does T.140 support that is needed. > That is what you get by specifying ITU-T T.140 instead of just saying UNICODE. > > There has been some mentioning about T.140 as a transmission mechanism, but > that is not > what it is. It is a simple set of rules around How to use Unicode in a real > time > conversation. > > We should look at this with open minds, but it is likely that we end up with > something > approximately like T.140 for the text coding. Let us see. > > Editing: > In a real time conversation you need to allow some "remote editing". The only > reliable way > is to allow erasure of the last character for correction. A number of > characters back must > be guarnateed to be stored in a buffer so that erasing into it can be done. > Insertion of new line is also needed. Agreed - so basically you need to send Back Space and Newline? > Allowing other forms of cursor positioning with effects on the remote side is > risky > because the layout must be allowed to be completely different. Therefore other > cursor > controls are not included in T.140. Make sense > > Rendering: > There might be some interest in adding colour to the text or other rendering > effects. This > is allowed in T.140, by using such codes from ISO 6429, but I do not know any > implementations supportning them. When you are in a real time text > conversation, you tend > to concentrate on the typing text and ignore such effects. Yes > It is important to remember that there are many varied writing directions in > the world, so > that it must be possible to display text with writing direction right to left > etc. Of course > > Using T.140 would make it easy to arrange gateways to other forms of text > conversation. I > have not heard anyone lacking any functions in T.140. > > > Negotiating the real time mode: > There must be a way to tell both sides that we now enter a real time text > session. That > should then cause transmission characteristics go real time, and reception and > display to > change to adding incoming text to a contigous field for incoming text and be > prepared to > do the edits. > I did not see any extra field for indication of modes duing the session, so a > new mime > subtype could be used as the way to signal to the applications to enter the > real time > mode. > Already in the SIP session setup it must be possible to see that the session > is offered in > order to handle real time text, so that both sides can select a common method. > So, the > current offering in MSRP with just m=message is not sufficient. > > It must also be planned to be possible to specify preferences and callee > capablilities for > text. > > Gunnar > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 26 17:02:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29361 for ; Sat, 26 Jun 2004 17:02:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeKJZ-0000TO-1K for simple-archive@ietf.org; Sat, 26 Jun 2004 17:02:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeKIf-0000G6-00 for simple-archive@ietf.org; Sat, 26 Jun 2004 17:01:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeKI2-0007gl-00; Sat, 26 Jun 2004 17:00:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeKFF-0005pC-Fp; Sat, 26 Jun 2004 16:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeKBr-0005Fa-04 for simple@megatron.ietf.org; Sat, 26 Jun 2004 16:54: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 QAA29087 for ; Sat, 26 Jun 2004 16:54:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeKBp-0006Qq-6G for simple@ietf.org; Sat, 26 Jun 2004 16:54:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeKAq-0006DP-00 for simple@ietf.org; Sat, 26 Jun 2004 16:53:20 -0400 Received: from av1-1-sn1.fre.skanova.net ([81.228.11.107]) by ietf-mx with esmtp (Exim 4.12) id 1BeK9o-0005mx-00 for simple@ietf.org; Sat, 26 Jun 2004 16:52:16 -0400 Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 93D3137E85; Sat, 26 Jun 2004 22:51:44 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 84B0D37E5C; Sat, 26 Jun 2004 22:51:44 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 59EBA37E49; Sat, 26 Jun 2004 22:51:44 +0200 (CEST) From: "Gunnar Hellstrom" To: "Cullen Jennings" Subject: RE: [Simple] RE: Betr.: Using MSRP for real time text conversation Date: Sat, 26 Jun 2004 22:51:42 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Cc: STF267 , "'Paul E. Jones'" , "'Toip list'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cullen, You say: "I was thinking that the senders application could allow them to select their preference for what they were sending and indicate in the arriving data that it was character by character mode so the receive could display and edit appropriately." Yes, and the way to indicate that could be by MIME type and subtype. Do you have any other proposal? Maybe you could instead introduce a new indicator in the "continue-flag" field to mean "display and treat this in real time mode". ? Such information seems related to the current variants of coding in that field. Ending real time mode would be indicated by sending the regular mime type, or using the current "continue-flag" codes. --------------------------------------- About colours, rendering effects and emoticons: T.140 can make use of the ones available in ISO 6429. It contains the common set of foreground colours, background colours, flashing, bold underlining etc. ISO 6429 is also mentioned in Unicode to be the normal set for rendering effects. I do not know if emoticons would be popular in real time mode if they were readily available from the user interface. Some emoticon-like characters are available in Unicode, but if a comprehensive set is needed, it would need to be introduced from other sources. If wanted. ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >Of Cullen Jennings >Sent: Saturday, June 26, 2004 9:44 PM >To: Gunnar Hellstrom >Cc: STF267; 'Paul E. Jones'; 'Toip list'; simple@ietf.org >Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text >conversation > > >On 6/26/04 9:41 AM, "Gunnar Hellstrom" wrote: > >> Negotiating the real time mode: >> There must be a way to tell both sides that we now enter a real time text >> session. That >> should then cause transmission characteristics go real time, and reception and >> display to >> change to adding incoming text to a contigous field for incoming text and be >> prepared to >> do the edits. > >Indeed - I was thinking that the senders application could allow them to >select their preference for what they were sending and indicate in the >arriving data that it was character by character mode so the receive could >display and edit appropriately. Somewhat interesting questions about getting >out of this mode. > >I was sort of wondering what the 2973bis draft was going to say about >getting and INT sequence in the T.140 packets. It seemed strangely silent on >this. > >It might be somewhat difficult to deal with given it is mixing signaling >into a media stream. I'm particularly interested to see the security >considerations for this. > > > > >_______________________________________________ >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-bounces@ietf.org Mon Jun 28 02:35:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11711 for ; Mon, 28 Jun 2004 02:35:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bepk6-000143-8V for simple-archive@ietf.org; Mon, 28 Jun 2004 02:35:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BepjA-0000tn-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 02:34:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bepio-0000jD-00; Mon, 28 Jun 2004 02:34:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BepfP-0007kY-9q; Mon, 28 Jun 2004 02:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BepeL-0007dW-DQ for simple@megatron.ietf.org; Mon, 28 Jun 2004 02:29: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 CAA11417 for ; Mon, 28 Jun 2004 02:29:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BepeJ-0007f0-AW for simple@ietf.org; Mon, 28 Jun 2004 02:29:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BepdO-0007UL-00 for simple@ietf.org; Mon, 28 Jun 2004 02:28:54 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bepcx-0007Jj-00 for simple@ietf.org; Mon, 28 Jun 2004 02:28:27 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5S6SRWR025024 for ; Mon, 28 Jun 2004 08:28:27 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 08:28:27 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Jun 2004 08:28:26 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" , alex.audu@alcatel.com Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Mon, 28 Jun 2004 08:28:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 28 Jun 2004 06:28:27.0086 (UTC) FILETIME=[1EFE56E0:01C45CD9] Content-Transfer-Encoding: quoted-printable Cc: "'hisham.khartabil@nokia.com'" , Adam Roach , cboulton@ubiquity.com, simple@ietf.org, Ben Campbell X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, So, do we have some kind of conclusion on this? Some people have asked for use-cases, and scenarios where this can be = useful, and I think a number of those have now been presented. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 15. kes=E4kuuta 2004 2:04 > To: alex.audu@alcatel.com > Cc: Adam Roach; 'hisham.khartabil@nokia.com';=20 > simple@ietf.org; Christer > Holmberg (JO/LMF); cboulton@ubiquity.com; Ben Campbell > Subject: Re: [Simple] Re: MSRP: Max message size indication >=20 >=20 >=20 >=20 > Alex Audu wrote: > > I think there is great value in end-point being able to signal the = > > maximum size of data it is > > willing /able to accept at a time. This information could=20 > be used by the=20 > > sender to, for example > > send a less memory intensive version of say an image,=20 > instead of a full=20 > > blown memory hungry > > version. This will allow the information to be communicated with a = > > decreased risk of truncation > > at first try. That makes for a more efficient communication (than=20 > > without this feature). >=20 > This is the most compelling argument for this feature that I=20 > have seen. >=20 > Paul >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 04:40:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16728 for ; Mon, 28 Jun 2004 04:40:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BergM-0001ph-Ia for simple-archive@ietf.org; Mon, 28 Jun 2004 04:40:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Berfb-0001cP-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 04:39:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Berej-00019W-00; Mon, 28 Jun 2004 04:38:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BerKF-00012Z-4k; Mon, 28 Jun 2004 04:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BerI1-0000py-SS for simple@megatron.ietf.org; Mon, 28 Jun 2004 04:14:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15752 for ; Mon, 28 Jun 2004 04:14:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BerHz-0004kt-K2 for simple@ietf.org; Mon, 28 Jun 2004 04:14:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BerGz-0004UF-00 for simple@ietf.org; Mon, 28 Jun 2004 04:13:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BerFx-0004DQ-00 for simple@ietf.org; Mon, 28 Jun 2004 04:12:49 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8CVN10670; Mon, 28 Jun 2004 11:12:31 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 11:11:45 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5S8Bjsd009354; Mon, 28 Jun 2004 11:11:45 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00TvvooN; Mon, 28 Jun 2004 11:11:29 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8BTH05818; Mon, 28 Jun 2004 11:11:29 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 11:10:42 +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] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Mon, 28 Jun 2004 11:10:43 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CBE@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Thread-Index: AcRa59E5Oe2PQiCHRrSAfObLc8HAvAB/yIng To: , X-OriginalArrivalTime: 28 Jun 2004 08:10:42.0983 (UTC) FILETIME=[6845EB70:01C45CE7] Content-Transfer-Encoding: quoted-printable Cc: toip@snowshore.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Gunnar Hellstrom > Sent: 25.June.2004 21:47 > To: Dean Willis > Cc: 'Toip list'; simple@ietf.org > Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 >=20 >=20 > Dean, >=20 > You seem to claim that MSRP for real time text would behave=20 > better in congestion than RTP > with text/t140. >=20 > I do not think this can be a decision factor for selecting=20 > one of these protocols before > the other. >=20 > RTP for text is not at all causing the continous load as=20 > voice and video. Transmission is > done just when there is text to transmit, and then we have a=20 > default transmission rate of > 3 packets per second. >=20 > In the last edition of rfc2793bis we added a lot of=20 > precautions for congestion. > But we also added that in case of severe congestion, other=20 > streams could be cut out, and > the conversation only continue in text in order for the whole=20 > conversational application > to behave well in the network. >=20 > Here is the last edition -06: ( - 07 should be out any day now ) > http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-06.txt >=20 >=20 > I do not see enough concerns about possibility to combine the=20 > text session with > simultaneous voice in the discussion. The thoughts about MSRP=20 > seems to be too far from the > real time media that I would not yet dare to rely on it as a=20 > base for real time text > during calls. >=20 > I think we would be better off, having a reference in MSRP=20 > saying that when there are real > time requirements, a text/t140 RTP stream SHALL be opened and=20 > the text conversation > performed there instead. I don't understand why this is MSRP's problem at all. MSRP is built for = the reason of instant message conversations, as the draft cleary states. = If MSRP does not meet you needs, you are free to implement any other = text media protocol you choose, but I do not believe that MSRP is the = right place to indicate this. So, stating in the MSRP draft what MSRP is designed for is enough. Thanks, Hisham >=20 > Then we can win-win in getting the mass deployment you expect=20 > for IM and the real time > behaviour that is needed in a more intensive text discussion. >=20 > Planning for emergency service text handling, for gatewaying=20 > to text in other networks etc > could continue as now and we would have a smooth transition=20 > and big market for future text > based services in all time aspects. > ------ >=20 > Did you see my question about what bandwidth an MSRP text=20 > session with three payload bytes > per packet every 300 ms would generate. That figure is=20 > important for judging if the > proposal to use MSRP is at all realistic. You who know MSRP=20 > can probably tell this easily. >=20 > ------ >=20 >=20 > Gunnar >=20 > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 > >-----Original Message----- > >From: Dean Willis [mailto:dean.willis@softarmor.com] > >Sent: Friday, June 25, 2004 5:33 PM > >To: Gunnar Hellstrom > >Cc: 'Toip list'; simple@ietf.org > >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 > >was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > > > > > >Gunnar listed out a good set of requirements in RE: [Sipping] RE: > >text/T140 and audio/t140 was:[avt]Comments/questions on > >draft-ietf-avt-rfc2793bis-04 > > > >I'd like to add one requirement that every Internet protocol should > >meet, but many (especially early protocols) do not. > > > >I'll phrase this as one absolutely critical requirement, and=20 > a couple of > >examples of what this means. I'll admit that the examples=20 > have a lot of > >overlap with each other. Perhaps someone has said this=20 > better -- if so, > >somebody please send me a reference . . . > > > >Big Requirement: A user of the Internet must not interfere=20 > unfairly with > >other users of the Internet. > > > >What does this mean in design terms? > > > >1) A protocol or suite of protocols supporting an application MUST be > >both sensitive and reactive to network behavior in real time. > > > >2) A protocol or suite of protocols supporting an=20 > application MUST not > >"flood" network links, stifle or starve other applications, or > >aggressively try to compensate for network limitations by using more > >bandwidth. > > > >3) A protocol or suite of protocols supporting an=20 > application MUST react > >to network performance issues in a "fail-safe" manner. If there are > >problems with the network, this means either "backing off" until the > >situation gets better, or reporting the conditions up the > >decision-making tree to an agent with the power to terminate=20 > or suspend > >the application operation until things get better (or=20 > possibly, that can > >make things better by taking actions outside the scope of the > >application protocol). > > > >4) A protocol or suite of protocols SHOULD be designed in such a way > >that implementations of applications using that protocol or suite of > >protocols meet the above requirements "by default", that is, without > >special effort on the part of the application builder. > > > >5) The best protocols "play nice" by recording network=20 > behavior in real > >time and taking corrective action. This includes things like: > > > >a) measuring end-to-end latency, drop rates, jitter, etc.=20 > and reducing > >transmission rates under degraded network conditions, perhaps by > >changing timing, encoding, buffering, packet size, or flo-control > >mechanisms. > > > >b) Interacting with network nodes to gain additional data=20 > about network > >behavior and using this data to adapt behavior as in A. An=20 > example here > >might be TCP explicit congestion notification (ECN) or frame-relay > >foward and backward explicit congestion notification (FECN and BECN). > > > >What does all this mean to us? > > > >Let's thnk about this in the terms of real-time-text and=20 > RTP. I'll admit > >that RTT/RTP can be made to work, even under bad network=20 > conditions, but > >is it a "good citizen" of the internet? > > > >Sure, RTCP gives us limited notification capability, and if used > >carefully in an application could meet most of the fundamental > >requirement. Problem is, nobody ever does it this way. When=20 > was the last > >time your GTT app popped up and said "I'm observing high loss on this > >link. Please type slower or give up." This is a failure of #4, above. > >Developers have to go out of their way to integrate RTCP=20 > status with the > >application and make the application adapt. Many implementors of RTP > >never get around to doing the RTCP part, and applications=20 > quite commonly > >ignore RTCP even if the stack they're written on supports it. > > > > > >#1 requires that our system sense and react to real network=20 > conditions. > >RTT/RTP as you have outlined it doesn't. Instead, RTT just=20 > assumes the > >network is lossy and congested, and sends things redundantly, obeying > >its own timers rather than reacting to the ebb and flow of=20 > the network > >beneath it. As a consequence, RTT/RTP violates #2 and #3 as it "out > >competes" other users by just blasting out redundant transmissions > >whether they're needed or not. > > > >I believe that, if we were designing the protocol today, RTP as it > >currently exists would not survive the review process. By requiring > >applications to deal with these complex transport issues, it=20 > makes the > >probability of "well-mannered" implementations quite low. We probably > >wouldn't use RTP for voice if we had something better-behaved, and we > >shouldn't use RTP for text when we have the option of using something > >that's better behaved. > > > >Sure, RTP can be made to run with DCCP, and it probably will be some > >day. But unfortunately, that's probably a few years out before we see > >any kind of "critical mass", and there'll be a whole new can of > >firewall/NAT worms to untangle before we can really count on=20 > it working > >in the field. > > > > > >So, what can we do now? > > > >Options include: > > > >1) Ignore these problems, because somebody else (perhaps the Bush > >administration) can be counted on to clean them up for us. > > > >2) If we really need a synchronous real-time end-to-end=20 > network, forget > >about IP and use ATM for real-time text applications. > > > >3) Require RSVP and per-RTT/RTP flow reservations. > > > >4) See how close we can get to meeting our real-time needs with a > >network-friendly protocol like MSRP. > > > > > >Personally, I prefer option 4, which begs the questions: > > > >What exactly do we want for real-time text, what part of it cannot be > >implemented on a network that is not always a real-time=20 > network, and can > >we get close enough to get something useful out of an MSRP-like > >protocol? And is the SIMPLE working group willing to tackle=20 > this mission? > > > > > > > >Here's a use case: > > > >I'm going to chat with Arnoud. I send him a MESSAGE asking=20 > if he wants > >to talk. Arnoud responds by INVITE-ing me to an MSRP session. We > >exchange a few slow-text messages. As the conversation warms up, we > >decide switch to real-time text by clicking the "send in real time" > >buttons on our texters (which I presume just changes the buffering > >behavior in MSRP). When we're done, we send BYEs. Throughout=20 > the whole > >conversation, the TCP stacks in our devices were making sure=20 > we "played > >nice" with the other network users. Every now and then, the=20 > timing was a > >bit off, but it was pretty close, and we didn't break=20 > anybody's network > >or interfere unfairly with other applications. That's a good=20 > way to use > >the Internet. > > > > > >-- > >Dean > > > > > > > > > > > > >=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-bounces@ietf.org Mon Jun 28 04:48:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17084 for ; Mon, 28 Jun 2004 04:48:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bero2-0003W8-UI for simple-archive@ietf.org; Mon, 28 Jun 2004 04:48:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BernF-0003Jl-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 04:47:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BermW-000368-00; Mon, 28 Jun 2004 04:46:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Berjp-0003c2-4M; Mon, 28 Jun 2004 04:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BergQ-0002uq-Ef for simple@megatron.ietf.org; Mon, 28 Jun 2004 04: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 EAA16749 for ; Mon, 28 Jun 2004 04:40:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BergO-0001pr-59 for simple@ietf.org; Mon, 28 Jun 2004 04:40:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Berfg-0001co-00 for simple@ietf.org; Mon, 28 Jun 2004 04:39:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Bereo-0001MU-00 for simple@ietf.org; Mon, 28 Jun 2004 04:38:30 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8cLN16557; Mon, 28 Jun 2004 11:38:21 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 11:38:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5S8cDhH019426; Mon, 28 Jun 2004 11:38:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 006eHij5; Mon, 28 Jun 2004 11:38:11 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8c5H07201; Mon, 28 Jun 2004 11:38:05 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 11:37:58 +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] Using MSRP for real time text conversation Date: Mon, 28 Jun 2004 11:37:58 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CC1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Using MSRP for real time text conversation Thread-Index: AcRbUo1Y3uOLi3bvRL+zYriNf1kcrwBlrU0A To: , , , X-OriginalArrivalTime: 28 Jun 2004 08:37:58.0278 (UTC) FILETIME=[36FC2260:01C45CEB] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Gunnar Hellstrom > Sent: 26.June.2004 10:38 > To: STF267; SIMPLE; Toip list > Subject: [Simple] Using MSRP for real time text conversation >=20 >=20 > This is a continuation of the discussion about the=20 > feasability of using simple:s instant > messaging protocol MSRP for real time text conversation. >=20 > (The discussion was held under the subject: "RE: [Simple] RE:=20 > [Sipping] RE: text/T140 and > audio/t140was:[avt]Comments/questions on=20 > draft-ietf-avt-rfc2793bis-04". I thought it was > time to make it more clear what the real subject is.) >=20 > One factor for checking the feasibility of using MSRP for=20 > real time text conversation is > the bandwidth it creates. >=20 > We have just had a discussion about the real time=20 > requirements for the real time > experience of a text conversation. We have an old recommended=20 > figure saying that we should > ship session conencts at least every 300 ms. Where did this figure come from? What does it mean in practice? Who = recommended it and why is it needed? > This is=20 > confirmed to give a good real time > experience. Some voices have been for transmission more=20 > often, but I think they are not > based on real experienced needs. Transmission less often=20 > creates an unpleasant chunkiness > in the perception of the dialogue. >=20 > So, for now, let us assume that transmission in 300 ms=20 > intervals is used (when there is > new text available for transmission ). >=20 > I made a calculation of a normal MSRP based text conversation=20 > exchange with material from > the MSRP specification. I don't understand why you would send the MSRP message before a user has = finished typing it. MSRP is for conversations between participants using = intant messages. It follows the definitions and requirements defined in = RFC2778 and RFC2779 respectively. If you have requirements for real time character by character text = sending with video for the hearing impared, for example, then you might = consider not using MSRP at all since this was not a requirement for it. = Again, MSRP is for conversations, mainly text. Regards, Hisham >=20 > This is the packet that needs to be sent for theree=20 > characters of text from the session: > ------------------Lower level headers - do not bother to calculate > here---------------------- > --------------------------IP V4 header 20 bytes ----- > ----------------------------TCP header 24 bytes ----- > ----------------------------MRSP SEND -189 bytes-including 3 bytes > payload-------------------- > MSRP SEND > Boundary: d93kswow > To-Path:msrp://bob.atlanta.com:8888/9di4ea > From-Path:msrp://alicepc.atlanta.com:7777/iau39 > TR-ID: 123 > Message-ID: 123 > Content-Type: "text/t140p" > Hi, > -------d93kswow+ > --------------------------------End of SEND request----------- >=20 > So, it sums up to 233 bytes transmission =3D 1864 bits. >=20 > In order to get the real time experience we should allow 3.3=20 > packets per second. That > makes 6150 bits/second. >=20 >=20 > The return direction will have approximately the same load by=20 > the 200 OK and the TCP > acknowledgements. >=20 >=20 > So, we would need approximately 6 kbit/s both ways for this=20 > text session. Most of it is > overhead, so it does not change much if we use the highest=20 > typing speed we design for, > that is 30 characters per second and type in Korean that will=20 > require 3 bytes UTF-8 per > character. >=20 >=20 > Using RTP, with text/t140 and two generations of redundancy=20 > that give good reliability, > consumes around 2 kbit/s in the same situation. >=20 > 6 kbit/s is a bit high load, but I would say that it is not=20 > totally out of scope. >=20 > What do you think? >=20 > Gunnar > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=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-bounces@ietf.org Mon Jun 28 05:08:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17966 for ; Mon, 28 Jun 2004 05:08:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bes7R-0007cA-OO for simple-archive@ietf.org; Mon, 28 Jun 2004 05:08:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bes6V-0007PF-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 05:07:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bes5r-0007Bf-00; Mon, 28 Jun 2004 05:06:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bes2T-0005Mb-P8; Mon, 28 Jun 2004 05:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Berxi-0004ym-OE for simple@megatron.ietf.org; Mon, 28 Jun 2004 04:58: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 EAA17414 for ; Mon, 28 Jun 2004 04:58:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Berxg-0005Tk-DY for simple@ietf.org; Mon, 28 Jun 2004 04:58:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Berwk-0005Ia-00 for simple@ietf.org; Mon, 28 Jun 2004 04:57:03 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Berw5-00057N-00 for simple@ietf.org; Mon, 28 Jun 2004 04:56:21 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8uJ202532; Mon, 28 Jun 2004 11:56:19 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 11:56:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5S8uCu2026378; Mon, 28 Jun 2004 11:56:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00cLqZ0Y; Mon, 28 Jun 2004 11:56:09 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8u9H06971; Mon, 28 Jun 2004 11:56:09 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 11:56:07 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 11:56:08 +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] XCAP Issue 8: Etag Scope Date: Mon, 28 Jun 2004 11:56:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CC2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 8: Etag Scope Thread-Index: AcRaJWVzly5VKQeNQjSbSUtbT7q7SgCx/BFg To: , X-OriginalArrivalTime: 28 Jun 2004 08:56:08.0832 (UTC) FILETIME=[C1017800:01C45CED] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I don't believe option 1 is the right way to go. CPCP requires multiple = users to edit the document. We thought we would leave this to later, but = Alan Johnston indicated that we need this in the first version of CPCP. I read very quickly through your text for option 3 and I like it. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 24.June.2004 05:40 > To: Simple WG > Subject: [Simple] XCAP Issue 8: Etag Scope >=20 >=20 > Folks, >=20 > I've spent a bunch of time since the interim trying to work=20 > out details > on how etag handling in XCAP needs to work, and to address=20 > the question > asked by Aki, which is how the client keeps its etags=20 > synchronized with > the server. As you may recall, at the last IETF meeting, we had > consensus that etags could be scoped to various sub-trees in=20 > a document, > rather than the whole document. >=20 > In a separate note, I will send out the text that I created=20 > for the xcap > specification which defines what this means. It concretely defines a > "scope" as a set of resources (each resource having a unique HTTP URI) > which all share the same value of an etag. Each resource can=20 > only be in > one scope. A change in one resource in a scope causes a change in the > etags for all other resources in that scope. A scope is structured as > either a subtree, or as the intersection of a sub-tree with sub-trees > beneath it. >=20 > Unfortunately, it got really complicated, as you can see from=20 > the text. > I think we need to simplify this a lot. I was able to come up=20 > with three > possible simplifications that made sense. They are: >=20 > 1. Revert to whats currently documented in xcap - there is only one > scope, and its for the entire document. Thus, the document, and all > elements and attributes within it, would have the same etag.=20 > This would > make it very hard to have two people independently edit separate parts > of the same document. If you want that, you need to have=20 > multiple documents. >=20 > 2. Redefine a scope as just a tree (never the intersection of a tree > with some of its sub-trees). Any elements outside of the=20 > defined scopes > have NO etag. Here's an example. Lets say I have a document that looks > like this: >=20 > > > STUFF > OTHER STUFF > >=20 > > > > > > > > > > > >=20 > The application usage would indicate that the scopes are=20 > defined by the > elements matching the expressions "/document/lists/list" and > "/document/users/happy-users/user" and=20 > "/document/users/sad-users/user". > Any element that matches one of those expression is the root of a > scope, and that scope would include the sub-tree rooted in=20 > that element. > Any element outside of those scopes has no etag. This includes the > document itself. >=20 > The rationale for this is that it matches how things would=20 > work if each > scope was actually a document in a filesystem, and every =20 > element above > it was a directory in that filesystem. Normally, those directories are > not directly referenceable as an HTTP resource, and don't inherently > have etags. >=20 > This appraoch vastly simplifies the procedure by which a client keeps > its etags up to date. It would also allow a single document=20 > to be edited > by multiple users, without stepping on each others toes. The=20 > drawback is > that, if you don't want to edit just pieces of the document,=20 > but rather > the document as a whole, you can't take advantage of etags to=20 > make sure > you don't clobber someone elses changes. >=20 > There are two variants for this approach: >=20 > Variant A: The definition of the scope boundaries are defined by the > application usage, and applied to all documents >=20 > Variant B: The definition of the scope boundaries are defiend by the > application usage. It can define a multiplicity of potential scope > boundaries, and each document uses one of them. We provide a=20 > way for the > client to dynamically determine which scope boundaries are in=20 > use. This > would allow some documents to have an etag for the whole document, and > others to have etags only for sub-trees within it. >=20 > 3. Go with the approach documented by the text I sent in the=20 > other note. >=20 >=20 > So, which do we do? I think we should do option 1. Its really=20 > simple. I > dont think any of our current usages would really require multiple > editors on the same document; it seems like we should always=20 > be able to > split it into multiple documents. >=20 > Thoughts? >=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 >=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-bounces@ietf.org Mon Jun 28 05:12:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18172 for ; Mon, 28 Jun 2004 05:12:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BesC9-0000pS-2z for simple-archive@ietf.org; Mon, 28 Jun 2004 05:12:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BesAa-0000TZ-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 05:11:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bes9i-0000Dm-00; Mon, 28 Jun 2004 05:10:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bes2U-0005Mu-EE; Mon, 28 Jun 2004 05:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Beryf-00054p-89 for simple@megatron.ietf.org; Mon, 28 Jun 2004 04:59: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 EAA17436 for ; Mon, 28 Jun 2004 04:58:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Beryd-0005eo-0n for simple@ietf.org; Mon, 28 Jun 2004 04:58:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Berxi-0005U7-00 for simple@ietf.org; Mon, 28 Jun 2004 04:58:04 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BerxH-0005J0-00 for simple@ietf.org; Mon, 28 Jun 2004 04:57:35 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8vVJ19366; Mon, 28 Jun 2004 11:57:31 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 11:57:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5S8vQwR006891; Mon, 28 Jun 2004 11:57:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00dfom7R; Mon, 28 Jun 2004 11:57:21 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S8vKH23759; Mon, 28 Jun 2004 11:57:20 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 11:57:20 +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] XCAP Etags: Text Defining Option 3 Date: Mon, 28 Jun 2004 11:57:19 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CC3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Etags: Text Defining Option 3 Thread-Index: AcRaJTY0jGcAW6DJQ2up5x+qaNCp4wCyJGbQ To: , X-OriginalArrivalTime: 28 Jun 2004 08:57:20.0018 (UTC) FILETIME=[EB6F9720:01C45CED] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I like this approach. Probably need to indicate that a scope is defined = by XPATH expressions pointing to MANDATORY elements. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 24.June.2004 05:43 > To: Simple WG > Subject: [Simple] XCAP Etags: Text Defining Option 3 >=20 >=20 > Please take a look at my email entitled "XCAP Issue 8: Etag Scope"=20 > before reading this. >=20 > The following text is what we would need to put into the doc=20 > to support=20 > option 3. >=20 >
>=20 > > Etags are associated with resources, with each resource being > identified by an HTTP URI. In XCAP, these resources can correspond to > a document, an XML element within a document, or an XML attribute > within an element. Just as the structure of the document creates > relationships between these resources, it also requires a creation of > relationships amongst the Etags associated with those resources. > >=20 >
>=20 > > These relationships are defined using the notion of a scope. A scope > is defined as a collection of resources, each of which shares the same > value of the Etag. When any one of those resources changes, due to a > PUT against that resource, the server assigns a new Etag for that > resource. It will also assign that same Etag to all of the other > resources within the same scope. A resource can only belong to one > scope. > >=20 > > A scope is always structured as the set of elements and attributes > that begin with an element in the document, and include all child > elements and their attributes, up to (and not including) any elements > which are members of another scope. As a result, a scope can be > thought of as either a sub-tree in the document, else as the > difference between a sub-tree and sub-trees underneath it. > >=20 > > One scope is said to be the parent of another scope if an element in > the parent scope is a parent of an element in the child > scope. Similarly, one scope is said to be the ancestor of another > scope, if an element in the ancestor scope is an ancestor of an > element in the descendant scope. > >=20 > > A scope marker is a rule for determining when a scope starts and > stops. It takes the form of a simple Xpath expression identifying a > sequence of elements, by element name only, starting from the root of > the document. For example, the Xpath expression "/foo/bar/baz" is a > scope marker. This means that, within an instance document, all > elements matching that expression represent the beginning of a scope > (and thus possibly the end of another scope). Each application usage > is responsible for identifying > the scope markers for the documents used by that application usage. > >=20 > > The scope markers for an application usage form a tree. Scope marker X > is the parent of scope marker Y if the following are both true: > >=20 > > The expression for X is a prefix > for the expression for Y, >=20 > For all other markers Z which are also prefixes for Y, X is not a > prefix for any of those Z. >=20 > >=20 > It > is important to understand that this tree of scope markers is static; > its associated with the schema for the document, and doesn't=20 > change for > different instance documents. > >=20 > > An actual scope, however, is based on an instance document. It is > uniquely identified by its root element and the markers that indicate > the end of the scope. The root element is always an element that > matches the Xpath expression corresponding to one of the scope > markers (say, marker X). The markers identifying the end of the scope > are all of the child markers of marker X. > >=20 > > Formally, a resource is associated with a scope if that=20 > resource is an=20 > element, > and that element is equal to, or a descendant of, the root element of > the scope, and that element is not within the elements selected by > evaluating the Xpath expressions that define the end of the scope. If > the resource is an attribute, the resource is within the scope if the > element containing that attribute is within the scope. Each document > has a special scope, called the document scope, which contains the > resource associated with the document itself, and includes any > resources not otherwise included in a scope based on the above > definitions. The document scope can be considered as the parent of all > other scopes. > >=20 > > Consider the following example. Lets say an application usage defines > a schema for a simple document format. This document format has a > single root element, , which can have any number of child elements, > . Each element can have any number of child elements . Each > element can have any number of child elements , and so on, all > the way to . Every element, through , has a single > attribute, id, which is a unique identifier for that element amongst > its siblings. > >=20 > > The application usages defines three scope markers. One marker is > called "root", and its identified by the Xpath expression "/a". The > next marker is called "layer 1" and its identified by the Xpath > expression "/a/b/c". The third marker is called "layer 2" and its > identified by the XPath expression "/a/b/c/d". target=3D"fig:scope"/> depicts an instance document in graphical > form. The dotted lines surround each of the 8 scopes that=20 > exist within the > document. The 9th scope, the document scope, is not shown. > >=20 >
> ............................... > ............................... Document Scope (1) >=20 > ............................... > . a . > . . > . / \ . > . / \ . > . / \ . (2) > . / \ . > . / \ . > . / \ . > . . > . b id=3D"1" b id=3D"2" . > ............................... > / \ \ > / \ \ > / \ \ > / \ \ > / \ \ > / \ \ > ............ ............ ..... > (3). c id=3D"1" . . c id=3D"2" .(4) . c . (5) > ............ ............ ..... > / \ / \ > / \ / \ > / \ / \ > / \ / \ > / \ / \ > / \ / \ > ........... ................. .......... .......... > . d id=3D"1". . d id=3D"2" . .d id=3D"1". .d = id=3D"2". > . . . . . . .......... > . | . . / \ . . | . (9) > . | . . / \ . . | . > . | . . / \ . . | . > . | . . / \ . . | . > . | . . / \ . . | . . > . | . . / \ . . | . > . e . .e e. . e . > ........... ................. .......... > (6) (7) (8) > ]]>
>
>=20 >
>=20 > > With this notion of scopes concretely defined, the rules for server > processing of Etags can be defined. > >=20 > > When a client modifies a resource, the server updates the etag for > that resource. Call this new etag value "e-new". Furthermore, the > server MUST set the etag for all other resources in the same scope to > "e-new". The server then identifies all resources that belong in > ancestor scopes to the one that was just modified, and it MUST modify > their etags as well, setting them to "e-new". The etags in all other > scopes MUST remain unchanged. > >=20 > > The sharing of etags amongst resources is mandatory here in order to > allow the client to maintain a synchronized view with the server on > the etag structure. > >=20 >
>=20 >
>=20 > > Client processing of etags follows the HTTP > specifications. Furthermore, because XCAP imposes additional > requirements on how etags are shared amongst other resources, a client > can implement the same algorithm as the server does, and keep track of > the etags associated with each element, attribute and document stored > on the server. It is useful to keep track of these when the client > wants to perform conditional modifications to various places in the > document. The client and server will remain in=20 > synchronization as long as no > errors occur, or no other clients attempt to make a change to the same > document. > >=20 > > In the latter case, when the client performs a conditional PUT (using > the If-Match or If-None-Match header fields), it will get a 412 error > response. When that happens, the client cannot assume that any of the > etags it currently possesses for the document in question are still > valid. To re-syncrhonize, it can optionally perform a series of GET > operations, which will return the current etags. The set of GET > operations to perform is purely a local choice. What follows is an > example algorithm which works well. > >=20 > > If a PUT against a resource fails, the client looks at its local copy > of the document, and figures out what scope its in. It then performs a > GET against the root element in that scope. The result of this GET > will update that section of the document tree. That will provide > sufficient information (the content of the scope and its etag) for the > client to re-do the request which just failed. > >=20 > > To determine the etags and content for the other scopes, the client > can perform the following steps. For each scope that is a sibling of > the scope which was just fetched, the client performs a HEAD operation > against the root element of that scope. The result of this HEAD > operation will indicate the etags for each of those scopes. If the > etag is unchanged from the one cached by the client, it knows that all > elements within this scope, and their children, are unchanged > (including their etags). If the HEAD operation indicates that the etag > has changed, it applies the algorithm described in this paragraph to > that scope as well. In addition to checking the etags of the siblings > of the current scope, the client also performs a HEAD against all > child scopes, in order to obtain their etags. The content of those > scopes is already known, only their etags need to be determined. > >=20 >=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 >=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-bounces@ietf.org Mon Jun 28 05:17:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18576 for ; Mon, 28 Jun 2004 05:17:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BesH0-00025a-Ae for simple-archive@ietf.org; Mon, 28 Jun 2004 05:17:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BesG4-0001ql-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 05:17:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BesF3-0001S0-00; Mon, 28 Jun 2004 05:15:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BesBX-0006QW-6V; Mon, 28 Jun 2004 05:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bes7K-0005pn-KC for simple@megatron.ietf.org; Mon, 28 Jun 2004 05:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17944 for ; Mon, 28 Jun 2004 05:07:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bes7I-0007b7-88 for simple@ietf.org; Mon, 28 Jun 2004 05:07:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bes6L-0007Nt-00 for simple@ietf.org; Mon, 28 Jun 2004 05:06:58 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bes5P-0007Br-00 for simple@ietf.org; Mon, 28 Jun 2004 05:05:59 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S95u612425; Mon, 28 Jun 2004 12:05:57 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 12:05:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5S95R7f000716; Mon, 28 Jun 2004 12:05:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00fNSq3n; Mon, 28 Jun 2004 12:05:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5S95FH01401; Mon, 28 Jun 2004 12:05:15 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 12:04:27 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 12:04:27 +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] XCAP Issue 9: Etags mostly useless for insert Date: Mon, 28 Jun 2004 12:04:27 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CC4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 9: Etags mostly useless for insert Thread-Index: AcRaJUEOwd4Gp4CKQamKZc+DH7HWZACyV0gQ To: , X-OriginalArrivalTime: 28 Jun 2004 09:04:27.0438 (UTC) FILETIME=[EA32B4E0:01C45CEE] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Option 1 gets my vote. If you want an if-match on a "scope", then you = would need to replace the whole "scope". Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 24.June.2004 06:19 > To: Simple WG > Subject: [Simple] XCAP Issue 9: Etags mostly useless for insert >=20 >=20 > While working through the text on etags, I ran into an interesting=20 > issue. Its not clear its a problem, but its something that=20 > needs to be=20 > documented if we decide its not. >=20 > The issue is that, when you do a conditional PUT (that is, a=20 > PUT with an=20 > If-Match containing an etag), the conditioning is based on=20 > the etag for=20 > *that* resource. There is no way to say, "perform this PUT on=20 > resource=20 > X, but only if the etag for resource Y has not changed". Why=20 > is this an=20 > issue? Well, let me give a concrete example. >=20 > Lets say I have a basic buddy list that looks like this: >=20 > > xmlns:xcap=3D"urn:ietf:params:xml:ns:xcap-must-understand" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > subscribeable=3D"true"> > > Bill Doe > > subscribeable=3D"true"> > > Joe Smith > > > Nancy Gross > > =20 > http://www.example.org/xcap/resource-lists/users/a/foo > > > > >=20 > and lets consider the simplest etag scope (this issue doesnt=20 > matter what=20 > we decide to do for etag scopes per issue 8), where every resource in=20 > the document has the same value for its etag. Its important to=20 > understand that etags are associated with a resource. Even if=20 > we decide=20 > that all resources will share the same value for their etags,=20 > they still=20 > each have their own etags. >=20 > Lets say that the current etag for this document (and all resources=20 > within it) is 2. I decide to insert a new entry, and so I do this: >=20 > PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ > resource-lists/list[@name=3D"friends"]/entry[@name=3D"Mikko"] > If-Match: 1 >=20 > >=20 >=20 >=20 > You would think that this insertion would be done if the document had=20 > not been modified (i.e., its etag was still 1), but that is NOT what=20 > this request will do. The conditioning here means that the=20 > PUT is only=20 > done if the etag for the resource in the request URI has an=20 > etag of 1.=20 > Of course, the resource in the request URI doesnt yet exist=20 > (thats why=20 > its an insert), so this request will be rejected with a 412. >=20 > Basically, there is no way to do an insert, and say, "don't do this=20 > insertion if the document hasn't changed since etag 1". You can say,=20 > "don't do this insert if this resource exists", by using an=20 > If-Not-Match: *. So, you can at least guarantee that what you=20 > think is=20 > an insertion, really is an insertion. >=20 > So, the question is, is this a problem? I don't think so. Or, more=20 > concretely, I couldn't think of a use case where this was a problem. >=20 > Consider the following example. Once again, we have the=20 > document above,=20 > and client A has a copy of it locally, in memory, with etag=20 > 1. Client 2=20 > makes a change, and the change it makes is to delete the=20 > close-friends=20 > list. Client 1 then tries to do an insert into this list, and=20 > so it does: >=20 > PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ > resource-lists/list[@name=3D"friends"]/ > list[@name=3D"close-friends"]/entry[@name=3D"Paul"] >=20 > >=20 > Fortunately, this will request will fail with a 409, since=20 > the parent of=20 > entry[@name=3D"Paul"] doesnt exist anymore. The client could=20 > then refetch=20 > the document and figure out why this error happened. >=20 > So, no problem here. >=20 > COnsider a different case. Client 1 has this list locally. Client 2=20 > changes the name of "close-friends" to "really-close-friends". Same=20 > thing happens as the previous example. >=20 > In yet another case, client 2 changes the subscribeable flag for=20 > close-friends from true to false. In this case, the insert done by=20 > client 1 will succeed. THe problem is that the client no longer has a=20 > correct copy of the document cached. If this is a problem, the client=20 > can refetch the document. >=20 > I'll also note that, if you use the xcap package, this problem pretty=20 > much goes away. >=20 > As far as I can tell, we have three choices about what to do=20 > about this=20 > "problem": >=20 > 1. document the situation so its clear what etags do and=20 > don't do for you >=20 > 2. instead of thinking about resources within a document as "not=20 > existing" when they aren't there, we can think about them as=20 > existing,=20 > but empty. If we stretch our imaginations a bit, we could think about=20 > assigning etags to empty resources. In that case, you basically never=20 > really do insertions; you only ever do modifications, and you might=20 > modify something from being empty to having actual value. In=20 > that case,=20 > you could usefully use etags to condition an "insertion" on=20 > whether or=20 > not the entire document has changed since you cached a copy.=20 > I consider=20 > this quite ugly. >=20 > 3. Define an HTTP extension which allows you to condition a request=20 > based on the etag of a different request on the server. >=20 > I think we should do 1. I think the costs of doing more complicated=20 > locking and transaction mechanisms (which is what we are=20 > talking about)=20 > are too high to pay for this functionality we want right now.=20 > If these=20 > things prove really important, we can work them in through=20 > xcap extensions. >=20 > Comments and input are welcome. >=20 > Thanks, > Jonathan R. >=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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 07:00:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24448 for ; Mon, 28 Jun 2004 07:00:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Betrq-0002HD-5h for simple-archive@ietf.org; Mon, 28 Jun 2004 07:00:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Betqr-00023P-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 06:59:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BetqH-0001pM-00; Mon, 28 Jun 2004 06:58:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Betid-0003bJ-NC; Mon, 28 Jun 2004 06:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeteH-0003BZ-BM for simple@megatron.ietf.org; Mon, 28 Jun 2004 06:46: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 GAA23997 for ; Mon, 28 Jun 2004 06:46:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeteE-0006wp-2V for simple@ietf.org; Mon, 28 Jun 2004 06:46:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BetdK-0006ke-00 for simple@ietf.org; Mon, 28 Jun 2004 06:45:07 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx with esmtp (Exim 4.12) id 1Betcl-0006WP-00 for simple@ietf.org; Mon, 28 Jun 2004 06:44:31 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i5SAi1mj002598 for ; Mon, 28 Jun 2004 05:44:01 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Jun 2004 11:44:00 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C614A84@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Simple WG Subject: RE: [Simple] XCAP Issue 8: Etag Scope Date: Mon, 28 Jun 2004 11:43:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 It certainly would be useful to see use cases if people think we need more complicated solutions. Looking for example at conferencing, most of the use cases I can think of do not need anything like the complexity. For example a conference creator may be privileged enough to modify the whole scope of the conference policy, but if he assigns privileges to others, then that is presumably because he does not wish to maintain the conference policy in those areas himself. Therefore in the majority of cases, I do not see both these users wishing to modify the document simultaneously, and if they do, a wait while one finishes is not precluded. I can envisage the members list of a conference policy being modified by the conference creator, while the attributes of a particular user are being modified by the user himself. Therefore while simultaneous modification of the conference policy may be attempted, either the compromise solution proposed by Jonathan below, or separate documents for different parts of conference policy, would cater for the majority of cases of simultaneous use. Therefore I would avoid going for the full flexible solution. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 24 June 2004 03:40 > To: Simple WG > Subject: [Simple] XCAP Issue 8: Etag Scope > > > Folks, > > I've spent a bunch of time since the interim trying to work > out details > on how etag handling in XCAP needs to work, and to address > the question > asked by Aki, which is how the client keeps its etags > synchronized with > the server. As you may recall, at the last IETF meeting, we had > consensus that etags could be scoped to various sub-trees in > a document, > rather than the whole document. > > In a separate note, I will send out the text that I created > for the xcap > specification which defines what this means. It concretely defines a > "scope" as a set of resources (each resource having a unique HTTP URI) > which all share the same value of an etag. Each resource can > only be in > one scope. A change in one resource in a scope causes a change in the > etags for all other resources in that scope. A scope is structured as > either a subtree, or as the intersection of a sub-tree with sub-trees > beneath it. > > Unfortunately, it got really complicated, as you can see from > the text. > I think we need to simplify this a lot. I was able to come up > with three > possible simplifications that made sense. They are: > > 1. Revert to whats currently documented in xcap - there is only one > scope, and its for the entire document. Thus, the document, and all > elements and attributes within it, would have the same etag. > This would > make it very hard to have two people independently edit separate parts > of the same document. If you want that, you need to have > multiple documents. > > 2. Redefine a scope as just a tree (never the intersection of a tree > with some of its sub-trees). Any elements outside of the > defined scopes > have NO etag. Here's an example. Lets say I have a document that looks > like this: > > > > STUFF > have etags. > > This appraoch vastly simplifies the procedure by which a client keeps > its etags up to date. It would also allow a single document > to be edited > by multiple users, without stepping on each others toes. The > drawback is > that, if you don't want to edit just pieces of the document, > but rather > the document as a whole, you can't take advantage of etags to > make sure > you don't clobber someone elses changes. > > There are two variants for this approach: > > Variant A: The definition of the scope boundaries are defined by the > application usage, and applied to all documents > > Variant B: The definition of the scope boundaries are defiend by the > application usage. It can define a multiplicity of potential scope > boundaries, and each document uses one of them. We provide a > way for the > client to dynamically determine which scope boundaries are in > use. This > would allow some documents to have an etag for the whole document, and > others to have etags only for sub-trees within it. > > 3. Go with the approach documented by the text I sent in the > other note. > > > So, which do we do? I think we should do option 1. Its really > simple. I > dont think any of our current usages would really require multiple > editors on the same document; it seems like we should always > be able to > split it into multiple documents. > > Thoughts? > > -- > 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-bounces@ietf.org Mon Jun 28 07:45:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26881 for ; Mon, 28 Jun 2004 07:45:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeuZQ-0005YC-9b for simple-archive@ietf.org; Mon, 28 Jun 2004 07:45:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeuYR-0005Ki-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 07:44:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BeuXw-00056s-00; Mon, 28 Jun 2004 07:43:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeuRp-0000h0-Cs; Mon, 28 Jun 2004 07:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeuNm-0000B5-96 for simple@megatron.ietf.org; Mon, 28 Jun 2004 07:33: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 HAA26292 for ; Mon, 28 Jun 2004 07:33:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeuNl-0002jB-QL for simple@ietf.org; Mon, 28 Jun 2004 07:33:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeuMp-0002TZ-00 for simple@ietf.org; Mon, 28 Jun 2004 07:32:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BeuLp-00021e-00 for simple@ietf.org; Mon, 28 Jun 2004 07:31:05 -0400 Received: from dynamicsoft.com ([63.113.46.120]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5SBUpbo001557; Mon, 28 Jun 2004 07:30:52 -0400 (EDT) Message-ID: <40E0014A.9040302@dynamicsoft.com> Date: Mon, 28 Jun 2004 07:30:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Simple] XCAP Issue 8: Etag Scope References: <475FF955A05DD411980D00508B6D5FB00C614A84@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C614A84@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > It certainly would be useful to see use cases if people think we need > more complicated solutions. I'd also like to understand the use cases for this. Hisham, can you provide some more? > > Looking for example at conferencing, most of the use cases I can > think of do not need anything like the complexity. > > For example a conference creator may be privileged enough to modify > the whole scope of the conference policy, but if he assigns > privileges to others, then that is presumably because he does not > wish to maintain the conference policy in those areas himself. > Therefore in the majority of cases, I do not see both these users > wishing to modify the document simultaneously, and if they do, a wait > while one finishes is not precluded. > > I can envisage the members list of a conference policy being modified > by the conference creator, while the attributes of a particular user > are being modified by the user himself. In such a case, one might want to split the policy up into several documents. For example, there might be one document for the overall policy, and then a document for each user that contains information that the user can modify about themself. -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-bounces@ietf.org Mon Jun 28 08:54:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02792 for ; Mon, 28 Jun 2004 08:54:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeveN-0007Ld-FT for simple-archive@ietf.org; Mon, 28 Jun 2004 08:54:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BevdY-00076y-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 08:53:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bevcm-0006p7-00; Mon, 28 Jun 2004 08:52:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BevT3-0002NA-2C; Mon, 28 Jun 2004 08:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BevL1-0000IQ-Jm for simple@megatron.ietf.org; Mon, 28 Jun 2004 08:34: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 IAA00932 for ; Mon, 28 Jun 2004 08:34:17 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BevL1-00026A-22 for simple@ietf.org; Mon, 28 Jun 2004 08:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BevHm-0001Gw-00 for simple@ietf.org; Mon, 28 Jun 2004 08:30:58 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BevFT-0000jr-00 for simple@ietf.org; Mon, 28 Jun 2004 08:28:35 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5SCRo222011; Mon, 28 Jun 2004 15:27:50 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 15:27:40 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5SCReBN023679; Mon, 28 Jun 2004 15:27:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00n8m1LP; Mon, 28 Jun 2004 15:27:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5SC53H28371; Mon, 28 Jun 2004 15:05:04 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 15:05:02 +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] XCAP Issue 8: Etag Scope Date: Mon, 28 Jun 2004 15:05:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CCF@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 8: Etag Scope Thread-Index: AcRdBYqq7pyQ+a/OSKiyq9LT9/XG4AAAZZlA To: , X-OriginalArrivalTime: 28 Jun 2004 12:05:02.0947 (UTC) FILETIME=[24AA2B30:01C45D08] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 28.June.2004 14:30 > To: Drage, Keith (Keith) > Cc: Simple WG > Subject: Re: [Simple] XCAP Issue 8: Etag Scope >=20 >=20 >=20 >=20 > Drage, Keith (Keith) wrote: >=20 > > It certainly would be useful to see use cases if people=20 > think we need > > more complicated solutions. >=20 > I'd also like to understand the use cases for this. Hisham, can you=20 > provide some more? There is a requirement where key participants, for example, get the = privilege to modify the Dial-out list, the security parameters in a = conference, or add a media stream to the conference. >=20 > >=20 > > Looking for example at conferencing, most of the use cases I can > > think of do not need anything like the complexity. > >=20 > > For example a conference creator may be privileged enough to modify > > the whole scope of the conference policy, but if he assigns > > privileges to others, then that is presumably because he does not > > wish to maintain the conference policy in those areas himself. > > Therefore in the majority of cases, I do not see both these users > > wishing to modify the document simultaneously, and if they=20 > do, a wait > > while one finishes is not precluded. > >=20 > > I can envisage the members list of a conference policy=20 > being modified > > by the conference creator, while the attributes of a particular user > > are being modified by the user himself. >=20 > In such a case, one might want to split the policy up into several=20 > documents. For example, there might be one document for the overall=20 > policy, and then a document for each user that contains=20 > information that=20 > the user can modify about themself. This method can be applied to media policy, I agree. /Hisham >=20 > -Jonathan R. > --=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 > _______________________________________________ > 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-bounces@ietf.org Mon Jun 28 10:21:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07369 for ; Mon, 28 Jun 2004 10:21:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bex0i-0004lC-NF for simple-archive@ietf.org; Mon, 28 Jun 2004 10:21:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bewzj-0004W6-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 10:20:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bewz5-0004Fs-00; Mon, 28 Jun 2004 10:19:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bewuk-0002fH-4m; Mon, 28 Jun 2004 10:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bewov-0000g7-ET for simple@megatron.ietf.org; Mon, 28 Jun 2004 10:09: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 KAA06145 for ; Mon, 28 Jun 2004 10:09:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bewou-0001v2-Ic for simple@ietf.org; Mon, 28 Jun 2004 10:09:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bewny-0001gx-00 for simple@ietf.org; Mon, 28 Jun 2004 10:08:19 -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 1BewnK-0001Ow-00 for simple@ietf.org; Mon, 28 Jun 2004 10:07:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2004 07:11:02 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5SE6TgK012400; Mon, 28 Jun 2004 07:06:31 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT21372; Mon, 28 Jun 2004 10:06:27 -0400 (EDT) Message-ID: <40E025E4.7040005@cisco.com> Date: Mon, 28 Jun 2004 10:06:28 -0400 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: Gunnar Hellstrom Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text conversation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , STF267 , "'Toip list'" , simple@ietf.org, "'Paul E. Jones'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > Cullen, > > You say: > "I was thinking that the senders application could allow them to > select their preference for what they were sending and indicate in the > arriving data that it was character by character mode so the receive could > display and edit appropriately." > > Yes, and the way to indicate that could be by MIME type and subtype. Do you have any other > proposal? > > Maybe you could instead introduce a new indicator in the "continue-flag" field to mean > "display and treat this in real time mode". ? Such information seems related to the > current variants of coding in that field. > > Ending real time mode would be indicated by sending the regular mime type, or using the > current "continue-flag" codes. I think the continue-flag would result in problems. For instance, relays might decide to buffer and merge message fragments, screwing up the realtime delivery. It seems to me that this is truly an application level semantic on how to render multiple incoming messages, so a content-type seems quite appropriate. Perhaps it would be sufficient to use text/t140 as the content type. I'm still dubious that sending this over MSRP is the right way to do, but it is at least worth discussing. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 12:53:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15820 for ; Mon, 28 Jun 2004 12:53:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezNp-0005M5-Nf for simple-archive@ietf.org; Mon, 28 Jun 2004 12:53:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BezMu-00056C-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 12:52:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BezM7-0004kj-00; Mon, 28 Jun 2004 12:51:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BezCv-0002T5-Um; Mon, 28 Jun 2004 12:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bez2o-0000Wg-C1 for simple@megatron.ietf.org; Mon, 28 Jun 2004 12:31:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14536 for ; Mon, 28 Jun 2004 12:31:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bez2n-0007By-As for simple@ietf.org; Mon, 28 Jun 2004 12:31:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bez1q-0006u2-00 for simple@ietf.org; Mon, 28 Jun 2004 12:30:46 -0400 Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx with esmtp (Exim 4.12) id 1Bez0x-0006Vl-00 for simple@ietf.org; Mon, 28 Jun 2004 12:29:51 -0400 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4BEC037E83; Mon, 28 Jun 2004 18:29:15 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3CA1C37E58; Mon, 28 Jun 2004 18:29:15 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 055A138014; Mon, 28 Jun 2004 18:29:14 +0200 (CEST) From: "Gunnar Hellstrom" To: "Paul Kyzivat" Subject: RE: [Simple] RE: Betr.: Using MSRP for real time text conversation Date: Mon, 28 Jun 2004 18:29:11 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40E025E4.7040005@cisco.com> Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , STF267 , "'Toip list'" , simple@ietf.org, "'Paul E. Jones'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I agree, this is an open feasability discussion. OK, of used, the MIME type would be the indicator that the usage is real time. Yes, it would be convenient if we could use text/t140. I am afraid though that the MIME registration happens to be linked to its RTP packetisation. Its use would influence both transmitter?s behaviour that need to transmit with a real time flow, and receiver?s behaviour who need to add incoming text to the incoming window. Seems uncomplicated. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >Of Paul Kyzivat >Sent: Monday, June 28, 2004 4:06 PM >To: Gunnar Hellstrom >Cc: Cullen Jennings; STF267; 'Toip list'; simple@ietf.org; 'Paul E. >Jones' >Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text >conversation > > > > >Gunnar Hellstrom wrote: >> Cullen, >> >> You say: >> "I was thinking that the senders application could allow them to >> select their preference for what they were sending and indicate in the >> arriving data that it was character by character mode so the receive could >> display and edit appropriately." >> >> Yes, and the way to indicate that could be by MIME type and subtype. Do you >have any other >> proposal? >> >> Maybe you could instead introduce a new indicator in the "continue-flag" field to mean >> "display and treat this in real time mode". ? Such information seems related to the >> current variants of coding in that field. >> >> Ending real time mode would be indicated by sending the regular mime type, or using the >> current "continue-flag" codes. > >I think the continue-flag would result in problems. For instance, relays >might decide to buffer and merge message fragments, screwing up the >realtime delivery. > >It seems to me that this is truly an application level semantic on how >to render multiple incoming messages, so a content-type seems quite >appropriate. Perhaps it would be sufficient to use text/t140 as the >content type. > >I'm still dubious that sending this over MSRP is the right way to do, >but it is at least worth discussing. > > 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-bounces@ietf.org Mon Jun 28 12:57:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16048 for ; Mon, 28 Jun 2004 12:57:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezRU-0006Mb-Jb for simple-archive@ietf.org; Mon, 28 Jun 2004 12:57:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BezQW-00066q-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 12:56:16 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BezPU-0005d7-00; Mon, 28 Jun 2004 12:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BezKu-0003gL-I2; Mon, 28 Jun 2004 12:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BezCD-0002JU-MT for simple@megatron.ietf.org; Mon, 28 Jun 2004 12:41: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 MAA15059 for ; Mon, 28 Jun 2004 12:41:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezCA-00023X-9P for simple@ietf.org; Mon, 28 Jun 2004 12:41:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BezBP-0001nK-00 for simple@ietf.org; Mon, 28 Jun 2004 12:40:39 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BezAR-0001WI-00 for simple@ietf.org; Mon, 28 Jun 2004 12:39:39 -0400 Received: from solstice (ew-dsl-81-171-8-127.eweka.nl [81.171.8.127]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i5SHLRdT079255; Mon, 28 Jun 2004 17:21:42 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200406281721.i5SHLRdT079255@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , "'Paul Kyzivat'" Subject: RE: [Simple] RE: Betr.: Using MSRP for real time text conversation Date: Mon, 28 Jun 2004 18:39:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRdLU2Y7NkgkD2/TvOKAvP+fW6txQAAPTOQ Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'STF267'" , "'Toip list'" , simple@ietf.org, "'Paul E. Jones'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit It is just User Agent behaviour and interface. Aka a switch on the IM client for a "real-time chat mode" with the current IM customer you communicate with. And perhaps only show that chat option if the other UA does support Interactive text. Nice to mention. Cheers Arnoud -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf Of Gunnar Hellstrom Sent: maandag 28 juni 2004 18:29 To: Paul Kyzivat Cc: Cullen Jennings; STF267; 'Toip list'; simple@ietf.org; 'Paul E. Jones' Subject: RE: [Simple] RE: Betr.: Using MSRP for real time text conversation I agree, this is an open feasability discussion. OK, of used, the MIME type would be the indicator that the usage is real time. Yes, it would be convenient if we could use text/t140. I am afraid though that the MIME registration happens to be linked to its RTP packetisation. Its use would influence both transmitter?s behaviour that need to transmit with a real time flow, and receiver?s behaviour who need to add incoming text to the incoming window. Seems uncomplicated. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >Of Paul Kyzivat >Sent: Monday, June 28, 2004 4:06 PM >To: Gunnar Hellstrom >Cc: Cullen Jennings; STF267; 'Toip list'; simple@ietf.org; 'Paul E. >Jones' >Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text >conversation > > > > >Gunnar Hellstrom wrote: >> Cullen, >> >> You say: >> "I was thinking that the senders application could allow them to >> select their preference for what they were sending and indicate in the >> arriving data that it was character by character mode so the receive could >> display and edit appropriately." >> >> Yes, and the way to indicate that could be by MIME type and subtype. Do you >have any other >> proposal? >> >> Maybe you could instead introduce a new indicator in the "continue-flag" field to mean >> "display and treat this in real time mode". ? Such information seems related to the >> current variants of coding in that field. >> >> Ending real time mode would be indicated by sending the regular mime type, or using the >> current "continue-flag" codes. > >I think the continue-flag would result in problems. For instance, relays >might decide to buffer and merge message fragments, screwing up the >realtime delivery. > >It seems to me that this is truly an application level semantic on how >to render multiple incoming messages, so a content-type seems quite >appropriate. Perhaps it would be sufficient to use text/t140 as the >content type. > >I'm still dubious that sending this over MSRP is the right way to do, >but it is at least worth discussing. > > Paul > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 13:06:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16505 for ; Mon, 28 Jun 2004 13:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezaG-0000rC-3J for simple-archive@ietf.org; Mon, 28 Jun 2004 13:06:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BezZM-0000cZ-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 13:05:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BezYZ-00008g-00; Mon, 28 Jun 2004 13:04:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BezQf-0004ms-Sd; Mon, 28 Jun 2004 12:56:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BezLs-0003oz-DJ for simple@megatron.ietf.org; Mon, 28 Jun 2004 12:51: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 MAA15779 for ; Mon, 28 Jun 2004 12:51:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezLr-0004rM-JT for simple@ietf.org; Mon, 28 Jun 2004 12:51:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BezKt-0004cf-00 for simple@ietf.org; Mon, 28 Jun 2004 12:50:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BezKL-0004Nb-00 for simple@ietf.org; Mon, 28 Jun 2004 12:49:53 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2004 12:47:55 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5SGnF6m003556; Mon, 28 Jun 2004 12:49:18 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT35085; Mon, 28 Jun 2004 12:49:16 -0400 (EDT) Message-ID: <40E04C0D.2070008@cisco.com> Date: Mon, 28 Jun 2004 12:49:17 -0400 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: Arnoud van Wijk Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text conversation References: <200406281721.i5SHLRdT079255@smtp.eweka.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'STF267'" , simple@ietf.org, "'Paul E. Jones'" , "'Toip list'" , "'Gunnar Hellstrom'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Arnoud van Wijk wrote: > It is just User Agent behaviour and interface. > Aka a switch on the IM client for a "real-time chat mode" with the current > IM customer you communicate with. And perhaps only show that chat option if > the other UA does support Interactive text. An advantage of this approach is how easy it is to negotiate, and to fall back to simpler behavior. The mechanism for listing supported content types is already present. Fallback is to (message oriented) text/plain. Paul > Nice to mention. > > Cheers > > Arnoud > > -----Original Message----- > From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Behalf > Of Gunnar Hellstrom > Sent: maandag 28 juni 2004 18:29 > To: Paul Kyzivat > Cc: Cullen Jennings; STF267; 'Toip list'; simple@ietf.org; 'Paul E. Jones' > Subject: RE: [Simple] RE: Betr.: Using MSRP for real time text conversation > > I agree, this is an open feasability discussion. > > OK, of used, the MIME type would be the indicator that the usage is real > time. > Yes, it would be convenient if we could use text/t140. I am afraid though > that the MIME > registration happens to be linked to its RTP packetisation. > > Its use would influence both transmitter?s behaviour that need to transmit > with a real > time flow, and receiver?s behaviour who need to add incoming text to the > incoming window. > > Seems uncomplicated. > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >>Of Paul Kyzivat >>Sent: Monday, June 28, 2004 4:06 PM >>To: Gunnar Hellstrom >>Cc: Cullen Jennings; STF267; 'Toip list'; simple@ietf.org; 'Paul E. >>Jones' >>Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text >>conversation >> >> >> >> >>Gunnar Hellstrom wrote: >> >>>Cullen, >>> >>>You say: >>>"I was thinking that the senders application could allow them to >>>select their preference for what they were sending and indicate in the >>>arriving data that it was character by character mode so the receive >> > could > >>>display and edit appropriately." >>> >>>Yes, and the way to indicate that could be by MIME type and subtype. Do >> > you > >>have any other >> >>>proposal? >>> >>>Maybe you could instead introduce a new indicator in the "continue-flag" >> > field to mean > >>>"display and treat this in real time mode". ? Such information seems >> > related to the > >>>current variants of coding in that field. >>> >>>Ending real time mode would be indicated by sending the regular mime >> > type, or using the > >>>current "continue-flag" codes. >> >>I think the continue-flag would result in problems. For instance, relays >>might decide to buffer and merge message fragments, screwing up the >>realtime delivery. >> >>It seems to me that this is truly an application level semantic on how >>to render multiple incoming messages, so a content-type seems quite >>appropriate. Perhaps it would be sufficient to use text/t140 as the >>content type. >> >>I'm still dubious that sending this over MSRP is the right way to do, >>but it is at least worth discussing. >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >> > > > > - > This list is maintained by Snowshore Networks - http://www.snowshore.com > All comments on this list are the comments of the message originators and > Snowshore is not to be held responsible for any actions or comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/toip_archive/maillist.html > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 15:00:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22598 for ; Mon, 28 Jun 2004 15:00:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf1Mm-0007dM-7C for simple-archive@ietf.org; Mon, 28 Jun 2004 15:00:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf1Lx-0007Nx-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 14:59:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf1LG-00076I-00; Mon, 28 Jun 2004 14:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1Fz-00011j-Ek; Mon, 28 Jun 2004 14:53:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1C4-0000Xo-C3 for simple@megatron.ietf.org; Mon, 28 Jun 2004 14:49: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 OAA22128 for ; Mon, 28 Jun 2004 14:49:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf1C3-0004qB-9i for simple@ietf.org; Mon, 28 Jun 2004 14:49:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf1BA-0004bj-00 for simple@ietf.org; Mon, 28 Jun 2004 14:48:33 -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 1Bf1Aa-0004Mt-00 for simple@ietf.org; Mon, 28 Jun 2004 14:47:56 -0400 Received: from [66.12.12.239] (bdsl.66.12.12.239.gte.net [66.12.12.239]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i5SIltq0002310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jun 2004 13:47:56 -0500 Message-ID: <40E067D8.5060902@softarmor.com> Date: Mon, 28 Jun 2004 13:47:52 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: <2038BCC78B1AD641891A0D1AE133DBB701797CBE@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CBE@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: toip@snowshore.com, gunnar.hellstrom@omnitor.se, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > I don't understand why this is MSRP's problem at all. > MRP is built for the reason of instant message conversations, > as the draft cleary states. If MSRP does not meet you needs, > you are free to implement any other text media protocol you > choose, but I do not believe that MSRP is the right place > to indicate this. > Ok, let's back up a step. I don't think anyone is suggesting that MSRP is currently expected to do real-time text. We have a set of valid requirements for real-time text. What we're discussing is how best to meet those requirements. I'm asking: 1) Could a congestion-safe protocol like MSRP be adapted to meet the requirements of real-time text? 2) If so, would this be better than using RTP? (and remember, "better" is a broad and subjective). 3) If so, would the people who are working on MSRP be interested in extending its requirement set to address the requirements of real time text? I believe Hisham is indicating above that he feels that MSRP is either an innapropriate starting point, or that as one of the people working on MSRP he's not interested in adapting it to meet the requirements of real-time text. Do I have that right, Hisham? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 15:25:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25123 for ; Mon, 28 Jun 2004 15:25:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf1l5-0006mJ-2F for simple-archive@ietf.org; Mon, 28 Jun 2004 15:25:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf1kA-0006Wn-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 15:24:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf1jj-0006Fz-00; Mon, 28 Jun 2004 15:24:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1eu-0006pR-SH; Mon, 28 Jun 2004 15:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1Pe-0006aU-08 for simple@megatron.ietf.org; Mon, 28 Jun 2004 15:03: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 PAA22758 for ; Mon, 28 Jun 2004 15:03:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf1Pc-0000bL-SQ for simple@ietf.org; Mon, 28 Jun 2004 15:03:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf1Oc-0000LL-00 for simple@ietf.org; Mon, 28 Jun 2004 15:02:27 -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 1Bf1No-00005U-00 for simple@ietf.org; Mon, 28 Jun 2004 15:01:36 -0400 Received: from [66.12.12.239] (bdsl.66.12.12.239.gte.net [66.12.12.239]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i5SJ1Zq0002361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jun 2004 14:01:36 -0500 Message-ID: <40E06B0C.5090700@softarmor.com> Date: Mon, 28 Jun 2004 14:01:32 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Toip list'" , simple@ietf.org Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: <40DC45C2.8080506@softarmor.com> In-Reply-To: <40DC45C2.8080506@softarmor.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dean Willis wrote: > I'll phrase this as one absolutely critical requirement, and a couple of > examples of what this means. I'll admit that the examples have a lot of > overlap with each other. Perhaps someone has said this better -- if so, > somebody please send me a reference . . . > > Big Requirement: A user of the Internet must not interfere unfairly with > other users of the Internet. Joel Halpern correctly pointed out to me that RFC2914/BCP41 is the definitive reference for this topic. Everybody who hasn't read it this week should go read it again. Joel also mentioned that the IESG seems to be serious about making sure that new work addresses the concerns raised in RFC2914. An example is the Forwarding and Control Element Seperation (FORCES) work, which now includes in its charter: o Specification of IP-based protocol for transport of the controlled objects. When the control and forwarding devices are separated beyond a single hop, ForCES will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. and as a consequence has effectively rejected use of UDP as a general transport for routing control traffic. -- dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 16:58:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04649 for ; Mon, 28 Jun 2004 16:58:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3D9-0007NQ-OI for simple-archive@ietf.org; Mon, 28 Jun 2004 16:58:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf32z-0005C3-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 16:48:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf2sg-00032n-01; Mon, 28 Jun 2004 16:37:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf2dn-0003ua-QS; Mon, 28 Jun 2004 16:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1xR-0000rZ-4I; Mon, 28 Jun 2004 15:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1ot-0008M3-UI for simple@megatron.ietf.org; Mon, 28 Jun 2004 15:29: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 PAA25441 for ; Mon, 28 Jun 2004 15:29:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf1os-00002o-Fe for simple@ietf.org; Mon, 28 Jun 2004 15:29:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf1o0-0007ar-00 for simple@ietf.org; Mon, 28 Jun 2004 15:28:41 -0400 Received: from av4-1-sn3.vrr.skanova.net ([81.228.9.111]) by ietf-mx with esmtp (Exim 4.12) id 1Bf1nP-0007II-00 for simple@ietf.org; Mon, 28 Jun 2004 15:28:03 -0400 Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id BA32137EA2; Mon, 28 Jun 2004 21:27:32 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id AA21B37E44; Mon, 28 Jun 2004 21:27:32 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 6376B38013; Mon, 28 Jun 2004 21:27:32 +0200 (CEST) From: "Gunnar Hellstrom" To: , , , Subject: RE: [Simple] Using MSRP for real time text conversation Date: Mon, 28 Jun 2004 21:27:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CC1@esebe019.ntc.nokia.com> Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham ------snip------ We have an old recommended >> figure saying that we should >> ship session contents at least every 300 ms. > >Where did this figure come from? What does it mean in practice? Who reco= mmended >it and why is it needed? -------snap------------ The tradition from real time text conversation is that immediate sending = gives best opportunity to have a good conversation. There are two services defined in ITU with real time text conversation. I= t is Text telephony, with the capability to use real time text and voice. View it a= s a modern extension to voice telephony. And it is Total Conversation, with an oppor= tunity to use video, text and voice in a call. View that as a modern extension to video= telephony. These services are defined in ITU-T F.703 Multimedia Conversation service= descriptions. The media involved in the multimedia services are described in ITU-T F.70= 0, where Annex 3 describes the text medium. There it is stated: "T2 - Good text conversation quality characterised by Font support for all characters in ISO-10646-1 No more than 1 corrupted, dropped or marked missing character per 500. Delay from character input in the transmitter to display in the receiver = shorter than 1 s." Next level is the presentation level, where ITU-T T.140 is the text cconv= ersation presentation protocol that specifies in section 6.1.1: "The requirements and the specific mechanisms for buffering are beyond th= e scope of this Recommendation. However if buffering is provided in the data channel, it = should not delay transmission more than 0.5 seconds and not be related to complete lines o= f input. Any grouping of data into blocks for transmission should be transparent to th= e text protocol." Then we have the transport levels, where we so far have had RFC2793 for R= TP packetization of conversational text, where the following is stated: "Packets are transmitted when there is valid T.140 data to transmit. T.140 specifies that T.140 data MAY be buffered for transmission with a maximum buffering time of 500 ms. A buffering time of 300 ms is RECOMMENDED, when the application or end-to-end network conditions are not known to require another value. " This all is to meet the balance between human need of flow in the discuss= ion, and the technical need of keeping low on bandwidth requirements. By using real time text conversation you simply relieve the transmittting= user from all stress of finishing a sentence so that the receiver can get it. And you r= elieve the receiver from nervous idling waiting for next complete sentence to arrive= . I do not know how so much text handling ended up to become message orient= ed. But I know that text messaging is valuable as well as text conversation, = and that we need to provide both services. Next question: >I don't understand why you would send the MSRP message before a user has >finished typing it. MSRP is for conversations between participants using= instant >messages. It follows the definitions and requirements defined in RFC2778= and >RFC2779 respectively. What we aim at is not only for hearing impaired users. And even if it was= , hearing impaired users tend to communicate with all users. I admit that the servi= ce is essential for hearing impaired users, but it should be evident from the motivation = above that it is of interest for all. We are in the era of rapid deployment of real time conversational service= s in the Internet, and need to have industry agreements on how to do that most eff= iciently. > >If you have requirements for real time character by character text sendi= ng with >video for the hearing impared, for example, then you might consider not = using >MSRP at all since this was not a requirement for it. Again, MSRP is for >conversations, mainly text. Sure, we already have RTP with text/t140 packetization, complete SIP sdp = declaration, awareness among emergency service actors, etc. So, this is so far only a feasability test initiated by simple members in= order to check if we could gain anything by joining the efforts. Your views in this discussion are valuable. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: Monday, June 28, 2004 10:38 AM >To: gunnar.hellstrom@omnitor.se; stf267@etsi.org; simple@ietf.org; >toip@snowshore.com >Subject: RE: [Simple] Using MSRP for real time text conversation > > > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf >> Of ext Gunnar Hellstrom >> Sent: 26.June.2004 10:38 >> To: STF267; SIMPLE; Toip list >> Subject: [Simple] Using MSRP for real time text conversation >> >> >> This is a continuation of the discussion about the >> feasability of using simple:s instant >> messaging protocol MSRP for real time text conversation. >> >> (The discussion was held under the subject: "RE: [Simple] RE: >> [Sipping] RE: text/T140 and >> audio/t140was:[avt]Comments/questions on >> draft-ietf-avt-rfc2793bis-04". I thought it was >> time to make it more clear what the real subject is.) >> >> One factor for checking the feasibility of using MSRP for >> real time text conversation is >> the bandwidth it creates. >> >> We have just had a discussion about the real time >> requirements for the real time >> experience of a text conversation. We have an old recommended >> figure saying that we should >> ship session conencts at least every 300 ms. > >Where did this figure come from? What does it mean in practice? Who reco= mmended >it and why is it needed? > >> This is >> confirmed to give a good real time >> experience. Some voices have been for transmission more >> often, but I think they are not >> based on real experienced needs. Transmission less often >> creates an unpleasant chunkiness >> in the perception of the dialogue. >> >> So, for now, let us assume that transmission in 300 ms >> intervals is used (when there is >> new text available for transmission ). >> >> I made a calculation of a normal MSRP based text conversation >> exchange with material from >> the MSRP specification. > >I don't understand why you would send the MSRP message before a user has >finished typing it. MSRP is for conversations between participants using= intant >messages. It follows the definitions and requirements defined in RFC2778= and >RFC2779 respectively. > >If you have requirements for real time character by character text sendi= ng with >video for the hearing impared, for example, then you might consider not = using >MSRP at all since this was not a requirement for it. Again, MSRP is for >conversations, mainly text. > >Regards, >Hisham > >> >> This is the packet that needs to be sent for theree >> characters of text from the session: >> ------------------Lower level headers - do not bother to calculate >> here---------------------- >> --------------------------IP V4 header 20 bytes ----- >> ----------------------------TCP header 24 bytes ----- >> ----------------------------MRSP SEND -189 bytes-including 3 bytes >> payload-------------------- >> MSRP SEND >> Boundary: d93kswow >> To-Path:msrp://bob.atlanta.com:8888/9di4ea >> From-Path:msrp://alicepc.atlanta.com:7777/iau39 >> TR-ID: 123 >> Message-ID: 123 >> Content-Type: "text/t140p" >> Hi, >> -------d93kswow+ >> --------------------------------End of SEND request----------- >> >> So, it sums up to 233 bytes transmission =3D 1864 bits. >> >> In order to get the real time experience we should allow 3.3 >> packets per second. That >> makes 6150 bits/second. >> >> >> The return direction will have approximately the same load by >> the 200 OK and the TCP >> acknowledgements. >> >> >> So, we would need approximately 6 kbit/s both ways for this >> text session. Most of it is >> overhead, so it does not change much if we use the highest >> typing speed we design for, >> that is 30 characters per second and type in Korean that will >> require 3 bytes UTF-8 per >> character. >> >> >> Using RTP, with text/t140 and two generations of redundancy >> that give good reliability, >> consumes around 2 kbit/s in the same situation. >> >> 6 kbit/s is a bit high load, but I would say that it is not >> totally out of scope. >> >> What do you think? >> >> Gunnar >> ------------------------------------------- >> Gunnar Hellstr=F6m >> Omnitor AB >> Renathv=E4gen 2 >> SE 121 37 Johanneshov >> SWEDEN >> +46 8 556 002 03 >> Mob: +46 708 204 288 >> www.omnitor.se >> Gunnar.Hellstrom@Omnitor.se >> -------------------------------------------- >> >> >> >> >> _______________________________________________ >> 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-bounces@ietf.org Mon Jun 28 17:40:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10233 for ; Mon, 28 Jun 2004 17:40:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3rt-0000H3-VL for simple-archive@ietf.org; Mon, 28 Jun 2004 17:40:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3hV-0005ne-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 17:30:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3Sv-0002rZ-00; Mon, 28 Jun 2004 17:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf22N-0001dV-Cu; Mon, 28 Jun 2004 15:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1v4-0000WG-5i; Mon, 28 Jun 2004 15:35:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25885; Mon, 28 Jun 2004 15:35:55 -0400 (EDT) Message-Id: <200406281935.PAA25885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 28 Jun 2004 15:35:55 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-filter-format-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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) Based Format for Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-filter-format-01.txt Pages : 19 Date : 2004-6-25 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-filter-format-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-filter-format-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: <2004-6-28151336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-filter-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-filter-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151336.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Jun 28 18:00:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13029 for ; Mon, 28 Jun 2004 18:00:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4BO-00046b-Up for simple-archive@ietf.org; Mon, 28 Jun 2004 18:00:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf42G-00025M-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 17:51:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3ov-0007Ed-00; Mon, 28 Jun 2004 17:37:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3aX-0007j5-PM; Mon, 28 Jun 2004 17:22:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf2IR-0005fH-77 for simple@megatron.ietf.org; Mon, 28 Jun 2004 16:00: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 QAA27906 for ; Mon, 28 Jun 2004 16:00:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf2IQ-00018l-0i for simple@ietf.org; Mon, 28 Jun 2004 16:00:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf2HU-0000nl-00 for simple@ietf.org; Mon, 28 Jun 2004 15:59:09 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf2GK-0000Bh-00 for simple@ietf.org; Mon, 28 Jun 2004 15:57:56 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SJuwLp008435; Mon, 28 Jun 2004 14:56:59 -0500 Message-ID: <40E0780A.8060703@dynamicsoft.com> Date: Mon, 28 Jun 2004 14:56:58 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Simple] Re: MSRP: Max message size indication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i5SJuwLp008435 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , simple@ietf.org, "'hisham.khartabil@nokia.com'" , "'Paul Kyzivat'" , alex.audu@alcatel.com, cboulton@ubiquity.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I believe the conclusion is to allow signaling max size you wish to=20 receive, but not to signal the max you intend to send. Christer Holmberg (JO/LMF) wrote: > Hi, >=20 > So, do we have some kind of conclusion on this? >=20 > Some people have asked for use-cases, and scenarios where this can be u= seful, and I think a number of those have now been presented. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 15. kes=E4kuuta 2004 2:04 >>To: alex.audu@alcatel.com >>Cc: Adam Roach; 'hisham.khartabil@nokia.com';=20 >>simple@ietf.org; Christer >>Holmberg (JO/LMF); cboulton@ubiquity.com; Ben Campbell >>Subject: Re: [Simple] Re: MSRP: Max message size indication >> >> >> >> >>Alex Audu wrote: >> >>>I think there is great value in end-point being able to signal the=20 >>>maximum size of data it is >>>willing /able to accept at a time. This information could=20 >> >>be used by the=20 >> >>>sender to, for example >>>send a less memory intensive version of say an image,=20 >> >>instead of a full=20 >> >>>blown memory hungry >>>version. This will allow the information to be communicated with a=20 >>>decreased risk of truncation >>>at first try. That makes for a more efficient communication (than=20 >>>without this feature). >> >>This is the most compelling argument for this feature that I=20 >>have seen. >> >> Paul >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:06:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14194 for ; Mon, 28 Jun 2004 18:06:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4GT-00057Q-My for simple-archive@ietf.org; Mon, 28 Jun 2004 18:06:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf48n-0003Sw-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 17:58:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3yG-00018x-00; Mon, 28 Jun 2004 17:47:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3hQ-0002Sl-26; Mon, 28 Jun 2004 17:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf2sV-0001sN-Hh for simple@megatron.ietf.org; Mon, 28 Jun 2004 16:37:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01922 for ; Mon, 28 Jun 2004 16:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf2sU-00032f-99 for simple@ietf.org; Mon, 28 Jun 2004 16:37:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf2ku-0001Ik-00 for simple@ietf.org; Mon, 28 Jun 2004 16:29: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 1Bf2e4-0007Sq-00 for simple@ietf.org; Mon, 28 Jun 2004 16:22:29 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SKL9Lp008594; Mon, 28 Jun 2004 15:21:09 -0500 Message-ID: <40E07DB4.5030000@dynamicsoft.com> Date: Mon, 28 Jun 2004 15:21:08 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) 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 Cc: Cullen Jennings , Rohan Mahy , Adam Roach , Hisham Khartabil , Robert Sparks , Chris Boulton Subject: [Simple] MSRP: Miscellaneous REPORT issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This note contains a few additional DSN issues, and the directions proposed by the design team. 1) We have had comments that the DSN file format may be two heavy weight. We propose that DSN bodies become optional in REPORT methods. We would make it possible to convey basic information in header fields in the REPORT method. A DSN body would become optional for when the reporting device desires a more expressive approach, at its discretion. We propose to add REPORT method header fields for MessageID and Status. The MessageID header would corelate with the MessageID of the original content. The status field will include a "scope" token, a status token, and a human readable string. Actual DSN payloads are optional. Positive REPORTs MAY contain a payload. Negative reports SHOULD contain a DSN payload. 2) Handling REPORTs that occur after a session is complete. Relays are not aware of the precise timing of the opening and closing of a session, so they cannot be prevented from originating REPORTS for sessions that have been closed. We propose to specify that a relay SHOULD NOT attempt to generate a report if it has reason to believe it will not be delivered. We do not define how it might have such reason, but will give a couple of examples (perhaps its URL has expired, or it has out-of-band knowledge.) Endpoints MAY accept REPORT requests after a session is over, but are not required to take any action to make it easy for someone to send one. Endpoints SHOULD NOT send DSN for expired sessions. There was also a question about how to handle the situation where you have requested positive reports, but We do not state any normative requirements about waiting for REPORT requests to arrive before ending a session, but will discuss choices and their concequences. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:06:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14358 for ; Mon, 28 Jun 2004 18:06:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Gs-0005C7-GS for simple-archive@ietf.org; Mon, 28 Jun 2004 18:06:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf49t-0003fw-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 17:59:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3zr-0001Qa-00; Mon, 28 Jun 2004 17:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3hw-0003CD-De; Mon, 28 Jun 2004 17:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf33f-0004bF-Dv for simple@megatron.ietf.org; Mon, 28 Jun 2004 16:48: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 QAA03025 for ; Mon, 28 Jun 2004 16:48:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf33e-0005IO-6B for simple@ietf.org; Mon, 28 Jun 2004 16:48:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf2tE-0003Ah-00 for simple@ietf.org; Mon, 28 Jun 2004 16:38:08 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf2lm-0001NH-00 for simple@ietf.org; Mon, 28 Jun 2004 16:30:26 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SKTuLp008683 for ; Mon, 28 Jun 2004 15:29:56 -0500 Message-ID: <40E07FC4.8050305@dynamicsoft.com> Date: Mon, 28 Jun 2004 15:29:56 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) 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] MSRP: Message Framing X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit In the interim meeting, there was a great deal of confusion about how the message boundaries worked, and how these related to MIME multipart boundaries. Furthermore, we have had proposals that framing can be more efficient if the boundary string was specified at a fixed position in the MSRP message. Therefore, the design team proposes to remove the Boundary header that was described in the 06 draft, and instead move the boundary string itself into a fixed position in the start line. If there are no objections to the approach, the details will be described in the next base spec draft version. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:06:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14460 for ; Mon, 28 Jun 2004 18:06:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4H9-0005EC-TF for simple-archive@ietf.org; Mon, 28 Jun 2004 18:06:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4Ad-0003yS-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:00:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf411-0001l6-00; Mon, 28 Jun 2004 17:50:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3iB-0003e8-FG; Mon, 28 Jun 2004 17:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf38x-0006Hu-Qi for simple@megatron.ietf.org; Mon, 28 Jun 2004 16:54:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03707 for ; Mon, 28 Jun 2004 16:54:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf38w-0006Pf-JL for simple@ietf.org; Mon, 28 Jun 2004 16:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf2yn-0004Kk-00 for simple@ietf.org; Mon, 28 Jun 2004 16:43: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 1Bf2s5-0002jq-00 for simple@ietf.org; Mon, 28 Jun 2004 16:36:57 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SKaRLp008724 for ; Mon, 28 Jun 2004 15:36:27 -0500 Message-ID: <40E0814B.8090405@dynamicsoft.com> Date: Mon, 28 Jun 2004 15:36:27 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) 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] MSRP: Surpression of duplicates X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The working group has gone round and round on whether (and how) we handle worry about the surpression of duplicate messages, in situations where a failure occurs, and the sender chooses to re-send content on a new session. Since we have introduced the concept of a MessageID, this becomes fairly easy to accomplish. If we specify the MessageID to be globally unique, or even just very likely to re-occur in a relatively short time period, then the receive can simply watch for duplicate messageIDs. The receiver's action upon receiving a duplicate would be entirely up to local policy (although simply displaying the duplicate to the user without any warning of duplication would be a bad choice.) This approach only works for detecting whole-content duplication, rather than chunk duplication. We recommend that chunks of a given message not be spread across more than one session. Within any given session, the chunking mechanism already provides a way to notice duplication--you can watch for byte-range overlaps. If there are no subtantive objections to the approach, the next draft version will describe the details. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:07:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14554 for ; Mon, 28 Jun 2004 18:07:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4HS-0005GH-3L for simple-archive@ietf.org; Mon, 28 Jun 2004 18:07:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4BH-00045M-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:00:51 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf42B-0001yi-00; Mon, 28 Jun 2004 17:51:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3iK-0003zK-ME; Mon, 28 Jun 2004 17:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3Br-0007DG-8D for simple@megatron.ietf.org; Mon, 28 Jun 2004 16:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04292 for ; Mon, 28 Jun 2004 16:57:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3Bp-000785-P9 for simple@ietf.org; Mon, 28 Jun 2004 16:57:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf31Z-0004yN-00 for simple@ietf.org; Mon, 28 Jun 2004 16:46:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf2sb-0002zp-03 for simple@ietf.org; Mon, 28 Jun 2004 16:37:29 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf2hj-00043H-2K for simple@ietf.org; Mon, 28 Jun 2004 16:26:15 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SKQBLp008668 for ; Mon, 28 Jun 2004 15:26:11 -0500 Message-ID: <40E07EE2.3040700@dynamicsoft.com> Date: Mon, 28 Jun 2004 15:26:10 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) 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] MSRP: Chunking Formats X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit There was quite a bit of discussion about what format should be used for "chunking" inside MSRP, and whether content-type should indicate the "chunking" format, or the actual message content format. After quite a bit of discussion, the design team decided that chunking was an integral part of MSRP, and it was not really appropriate to rely on special body formats for this. Furthermore, we were proposing usages that were not entirely in keeping with the original specification for either multipart/byteranges or message/partial types. Therefore, we propose that we promote the byte range information described in the 06 draft into the standard SEND header fields, and make chunking into an integral feature of SEND. The precise details will be in the next draft version. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:08:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14847 for ; Mon, 28 Jun 2004 18:08:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4IR-0005d5-G9 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:08:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4DP-0004c2-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:03:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf44L-0002Xe-00; Mon, 28 Jun 2004 17:53:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3ij-0004or-Hz; Mon, 28 Jun 2004 17:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3Ik-0001i3-GK for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:04: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 RAA05522 for ; Mon, 28 Jun 2004 17:04:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3Ij-0000mm-76 for simple@ietf.org; Mon, 28 Jun 2004 17:04:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf394-0006R0-00 for simple@ietf.org; Mon, 28 Jun 2004 16:54:30 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf2yy-0004Hp-00 for simple@ietf.org; Mon, 28 Jun 2004 16:44:04 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SKhYLp008755 for ; Mon, 28 Jun 2004 15:43:35 -0500 Message-ID: <40E082F6.4050803@dynamicsoft.com> Date: Mon, 28 Jun 2004 15:43:34 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) 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] MSRP: Send vs. Visit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit At the interim meeting, we proposed that the offerer always initiated the connection, if required, and that the offerer would immediately send some request. If it had content to send, it could immediately send a SEND request. We had controversy over where, in a situation where it did _not_ have immediate content, it should send a VISIT request, or a SEND request with no content. The design team discussed this extensively, and came to the conclusion that there were some boundary conditions where VISIT could be more efficient. For example, we could define VISIT to only go so far as the first hop that was proposed by the peer. However, we agreed that any such boundary condition gains were not worth the complexity of having to use SEND sometimes and VISIT sometimes. Therefore, we propose that we remove the VISIT method entirely, and specify that the offerer always sends a SEND request immediately upon opening a session. If the offerer has no immediate content to send, it may choose not to put a body in the SEND request. If there are no substantive objections, the next draft will reflect this. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:08:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14946 for ; Mon, 28 Jun 2004 18:08:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Ik-0005qN-7L for simple-archive@ietf.org; Mon, 28 Jun 2004 18:08:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4Dp-0004gJ-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:03:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf452-0002fr-00; Mon, 28 Jun 2004 17:54:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3kV-0005eD-Ie; Mon, 28 Jun 2004 17:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3Rl-0004Zt-UL for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:13: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 RAA06442 for ; Mon, 28 Jun 2004 17:13:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3Rk-0002jh-MJ for simple@ietf.org; Mon, 28 Jun 2004 17:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3Gs-0000RW-00 for simple@ietf.org; Mon, 28 Jun 2004 17:02:35 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf37I-000622-00 for simple@ietf.org; Mon, 28 Jun 2004 16:52:40 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SKqALp008798 for ; Mon, 28 Jun 2004 15:52:10 -0500 Message-ID: <40E084FA.4030007@dynamicsoft.com> Date: Mon, 28 Jun 2004 15:52:10 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) 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] MSRP: updates and re-invites X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We have had a lot of discussion on how to handle updated offers in SIP updates and re-invites. We had made some proposals back when we negotiated connection direction that are not really relevant any more. The design team spent some time discussing this, and came up with a proposal: Reconnection no longer an issue with connection sharing. TCP connection establishment is done on-demand. Therefore we do not need a way to signal a desire to establish a new TCP session. The offerer of a new sdp exchange assumes the role of offerer for all purposes, regardless of whether it was the origininal offerer. An offerer or answer is effectively unchanged if the path does not change from the previous version. If either side changes the path, then we effectively have a new session. If offerer does not change anything, answerers can still make changes. Answerer must always answer with a currently valid path. These could be the same as before the update, or different. Local policy may choose to re-invite to fix session problems without user interaction, or give user a choice. (examples: you get an error report to the initial send, a mobile device looses connectivity through tunnel, etc.) I invite everyone who cares to think this through, and make sure we are not breaking something important. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:15:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16163 for ; Mon, 28 Jun 2004 18:15:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Pa-00000Q-FM for simple-archive@ietf.org; Mon, 28 Jun 2004 18:15:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4M1-0006j5-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:11:58 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4Jy-00063A-02; Mon, 28 Jun 2004 18:09:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf4Ak-0007Xb-1T; Mon, 28 Jun 2004 18:00:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf461-0007As-DY; Mon, 28 Jun 2004 17:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3oq-00073C-7s for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:37: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 RAA09363 for ; Mon, 28 Jun 2004 17:37:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3oo-0007IH-U3 for simple@ietf.org; Mon, 28 Jun 2004 17:37:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3cD-0004kt-00 for simple@ietf.org; Mon, 28 Jun 2004 17:24:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf3QJ-0002HD-00 for simple@ietf.org; Mon, 28 Jun 2004 17:12:19 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf3Ph-0005oi-9g for simple@ietf.org; Mon, 28 Jun 2004 17:11:41 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SLB9Lp008952; Mon, 28 Jun 2004 16:11:09 -0500 Message-ID: <40E0896D.4000601@dynamicsoft.com> Date: Mon, 28 Jun 2004 16:11:09 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: <2038BCC78B1AD641891A0D1AE133DBB701797CBE@esebe019.ntc.nokia.com> <40E067D8.5060902@softarmor.com> In-Reply-To: <40E067D8.5060902@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: toip@snowshore.com, hisham.khartabil@nokia.com, gunnar.hellstrom@omnitor.se, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The fact that this conversation is spread over multiple threads and working groups makes it near impossible to track the entire history, so I apologize for coming in late, and if I am covering old ground. Comments inline: Dean Willis wrote: > hisham.khartabil@nokia.com wrote: > > >> >> I don't understand why this is MSRP's problem at all. > > > MRP is built for the reason of instant message conversations, > >> as the draft cleary states. If MSRP does not meet you needs, you are >> free to implement any other text media protocol you choose, but I do >> not believe that MSRP is the right place to indicate this. >> > > Ok, let's back up a step. I don't think anyone is suggesting that MSRP > is currently expected to do real-time text. > > We have a set of valid requirements for real-time text. What we're > discussing is how best to meet those requirements. > > > I'm asking: > > 1) Could a congestion-safe protocol like MSRP be adapted to meet the > requirements of real-time text? No. A congestion-safe protocol might, but one like MSRP most certainly cannot. MSRP is message oriented. If we get into situations where we send one character per message, we will have an absurd overhead rate. MSRP is designed for a set of problems almost 180 degrees opposite of real-time text. > > 2) If so, would this be better than using RTP? (and remember, "better" > is a broad and subjective). > > 3) If so, would the people who are working on MSRP be interested in > extending its requirement set to address the requirements of real time > text? No. That would involve completely starting over with MSRP, and reduce is usefulness for the problem it was intended to solve. > > I believe Hisham is indicating above that he feels that MSRP is either > an innapropriate starting point, or that as one of the people working on > MSRP he's not interested in adapting it to meet the requirements of > real-time text. Do I have that right, Hisham? > Not to speak for Hisham, but as the editor of MSRP, I strongly believe it is an innappropriate starting point for real-time-text. > -- > Dean > > _______________________________________________ > 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-bounces@ietf.org Mon Jun 28 18:16:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16551 for ; Mon, 28 Jun 2004 18:16:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Qe-0000Cx-9B for simple-archive@ietf.org; Mon, 28 Jun 2004 18:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4NI-000736-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:13:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4KD-00063A-01; Mon, 28 Jun 2004 18:10:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf47x-0007TL-7g; Mon, 28 Jun 2004 17:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3zL-0001uA-7I; Mon, 28 Jun 2004 17:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3hw-0003C6-5w for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:30: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 RAA08266 for ; Mon, 28 Jun 2004 17:30:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3hu-0005sV-Qt for simple@ietf.org; Mon, 28 Jun 2004 17:30:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3TY-00033h-00 for simple@ietf.org; Mon, 28 Jun 2004 17:15:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf3IV-0000ev-00 for simple@ietf.org; Mon, 28 Jun 2004 17:04:15 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SL3jLp008883; Mon, 28 Jun 2004 16:03:45 -0500 Message-ID: <40E087B1.2080700@dynamicsoft.com> Date: Mon, 28 Jun 2004 16:03:45 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Murty Dasari Subject: Re: [Simple] MSRP Boundary header References: <20040623194530.RUYQ1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> In-Reply-To: <20040623194530.RUYQ1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i5SL3jLp008883 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The reason is, we added a requirement to be able abort a message without=20 destroying framing for the TCP connection. The boundary approach has=20 that property, content-length does not. Murty Dasari wrote: > Hello, >=20 > =20 >=20 > I=92ve a question about MSRP (based on=20 > draft-ietf-simple-message-sessions-06.txt) =93Closing=94 field. >=20 > =20 >=20 > What is the need for a =93Closing=94 field? >=20 > =20 >=20 > Can=92t we use =93Content-Length=94 similar to HTTP for determining the= =20 > message body length? If this is there for =93Continuation-Flag=94 then=20 > probably we can have another header that indicates continuation status.= =20 > Though it might not be lot of work to determine the =93closing=94 tag, = it=20 > might be easy for the relays and clients to retrieve the message body=20 > based on content-length header; further, we don=92t have to add=20 > restrictions on presence of =93boundary=94 in the message body in this = case. >=20 > =20 >=20 > This question might have brought-up/answered earlier, but I couldn=92t=20 > find out from the archives. Appreciate any comments. >=20 > =20 >=20 > Thanks for your time. >=20 > - Murty >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > 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-bounces@ietf.org Mon Jun 28 18:16:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16617 for ; Mon, 28 Jun 2004 18:16:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Qp-0000Es-6T for simple-archive@ietf.org; Mon, 28 Jun 2004 18:16:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4NS-000754-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:13:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4KF-00063A-01; Mon, 28 Jun 2004 18:10:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf46Y-0007PR-Hj; Mon, 28 Jun 2004 17:55:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3ve-0000VG-2L; Mon, 28 Jun 2004 17:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3gu-0001tj-M9 for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:29: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 RAA08040 for ; Mon, 28 Jun 2004 17:29:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3gt-0005ga-4Z for simple@ietf.org; Mon, 28 Jun 2004 17:29:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3S9-0002oO-00 for simple@ietf.org; Mon, 28 Jun 2004 17:14: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 1Bf3HI-0000Qu-00 for simple@ietf.org; Mon, 28 Jun 2004 17:03:00 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SL2TLp008862; Mon, 28 Jun 2004 16:02:29 -0500 Message-ID: <40E08764.7060703@dynamicsoft.com> Date: Mon, 28 Jun 2004 16:02:28 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Murty Dasari Subject: Re: [Simple] MSRP: Lack of version in the protocol References: <20040623195650.RXLR1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> In-Reply-To: <20040623195650.RXLR1757.mm-ismta4.bizmailsrvcs.net@opwvmdasari1> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i5SL2TLp008862 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This was discussed in the working group some time back. The consensus=20 was that there was no use for a version indicator, since MSRP would=20 never negotiate versions. Since MSRP is _always_ negotiated with an external signaling protocol,=20 any version negotiation belongs there. Any version updates to MSRP must=20 describe how to indicate the new version in the sdp exchange. Murty Dasari wrote: > Hi, >=20 > =20 >=20 > I=92ve a question about MSRP protocol (based on=20 > draft-ietf-simple-message-sessions-06.txt) =20 >=20 > =20 >=20 > Currently MSRP messages do not contain any version information. Wouldn=92= t=20 > it be helpful to have major and minor version numbers similar to HTTP? >=20 > Is there some other way to support multiple protocol revisions and=20 > future MSRP methods? >=20 > =20 >=20 > Appreciate any comments. >=20 > =20 >=20 > thanks, >=20 > - Murty >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > 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-bounces@ietf.org Mon Jun 28 18:20:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17240 for ; Mon, 28 Jun 2004 18:20:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4U3-00011i-Q8 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4SO-0000ca-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:18:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf4PY-0007Xp-00; Mon, 28 Jun 2004 18:15:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf48h-00005y-3h; Mon, 28 Jun 2004 17:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf41O-0002cw-BP for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:50: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 RAA11105 for ; Mon, 28 Jun 2004 17:50:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf41M-0001uf-W0 for simple@ietf.org; Mon, 28 Jun 2004 17:50:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3mu-0006xi-00 for simple@ietf.org; Mon, 28 Jun 2004 17:35:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf3ZZ-0004Cv-00 for simple@ietf.org; Mon, 28 Jun 2004 17:21:53 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SLLMLp009007; Mon, 28 Jun 2004 16:21:23 -0500 Message-ID: <40E08BD2.4070707@dynamicsoft.com> Date: Mon, 28 Jun 2004 16:21:22 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 References: <2038BCC78B1AD641891A0D1AE133DBB701797CBE@esebe019.ntc.nokia.com> <40E067D8.5060902@softarmor.com> <40E0896D.4000601@dynamicsoft.com> In-Reply-To: <40E0896D.4000601@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: toip@snowshore.com, hisham.khartabil@nokia.com, gunnar.hellstrom@omnitor.se, simple@ietf.org, Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit OK, I sent that before entirely thinking it through. The streaming capabilities in MSRP might make it possible to deliver what appears to be real-time-text without having a whole message per char. But this would require a boat-load of restrictions on how the protocol is used which I think are way out of scope for MSRP and SIMPLE. If, after the MSRP base is done, someone wants to specify such an extension, I suppose that is their perogative. Ben Campbell wrote: > The fact that this conversation is spread over multiple threads and > working groups makes it near impossible to track the entire history, so > I apologize for coming in late, and if I am covering old ground. > > Comments inline: > > Dean Willis wrote: > >> hisham.khartabil@nokia.com wrote: >> >> >>> >>> I don't understand why this is MSRP's problem at all. >> >> >> > MRP is built for the reason of instant message conversations, >> >>> as the draft cleary states. If MSRP does not meet you needs, you are >>> free to implement any other text media protocol you choose, but I do >>> not believe that MSRP is the right place to indicate this. >>> >> >> Ok, let's back up a step. I don't think anyone is suggesting that MSRP >> is currently expected to do real-time text. >> >> We have a set of valid requirements for real-time text. What we're >> discussing is how best to meet those requirements. >> >> >> I'm asking: >> >> 1) Could a congestion-safe protocol like MSRP be adapted to meet the >> requirements of real-time text? > > > No. A congestion-safe protocol might, but one like MSRP most certainly > cannot. MSRP is message oriented. If we get into situations where we > send one character per message, we will have an absurd overhead rate. > > MSRP is designed for a set of problems almost 180 degrees opposite of > real-time text. > >> >> 2) If so, would this be better than using RTP? (and remember, "better" >> is a broad and subjective). >> >> 3) If so, would the people who are working on MSRP be interested in >> extending its requirement set to address the requirements of real time >> text? > > > No. That would involve completely starting over with MSRP, and reduce is > usefulness for the problem it was intended to solve. > >> >> I believe Hisham is indicating above that he feels that MSRP is either >> an innapropriate starting point, or that as one of the people working >> on MSRP he's not interested in adapting it to meet the requirements of >> real-time text. Do I have that right, Hisham? >> > > Not to speak for Hisham, but as the editor of MSRP, I strongly believe > it is an innappropriate starting point for real-time-text. > > >> -- >> Dean >> >> _______________________________________________ >> 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-bounces@ietf.org Mon Jun 28 18:28:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17751 for ; Mon, 28 Jun 2004 18:28:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4c0-0003MD-4r for simple-archive@ietf.org; Mon, 28 Jun 2004 18:28:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4b3-00036h-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:27:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf4a6-0002dX-00; Mon, 28 Jun 2004 18:26:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4Pv-0001CS-Bt; Mon, 28 Jun 2004 18:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf48w-0000Bb-DS for simple@megatron.ietf.org; Mon, 28 Jun 2004 17:58: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 RAA12526 for ; Mon, 28 Jun 2004 17:58:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf48v-0003U5-2y for simple@ietf.org; Mon, 28 Jun 2004 17:58:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3yQ-0001Fa-00 for simple@ietf.org; Mon, 28 Jun 2004 17:47:35 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf3jv-00069b-00 for simple@ietf.org; Mon, 28 Jun 2004 17:32:35 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5SLWLbo001816; Mon, 28 Jun 2004 17:32:21 -0400 (EDT) Message-ID: <40E08E4B.8060603@dynamicsoft.com> Date: Mon, 28 Jun 2004 17:31:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jing Qian Subject: Re: [Simple] How to get SIP phone presence info References: <2038BCC78B1AD641891A0D1AE133DBB701797B9D@esebe019.ntc.nokia.com> <40DAE695.818391E1@alcatel.com> In-Reply-To: <40DAE695.818391E1@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit There are a few possibilities: 1. There is an RPID extension for indicating whether or not a user is on the phone or not. The IP PBX can send a PUBLISH message for the AOR of the user, including a presence document indicating this information. 2. I had submitted, quite some time back, a proposal for adding phone status information to pidf: http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt There was pushback to all of this in pidf, and these days, I am inclined to agree. I think that phone status is really a separate event package. I have in mind to submit an update to this document defining a separate event package, but there is nothing right now. 3. The dialog event package and reg event package, when put together, tell you a lot about the status of a SIP phone. -Jonathan R. Jing Qian wrote: > Hi, > > I am working on the Presence Server to get the presence > status of a specific user's SIP phone - on the call , not on > the call - a user based SIP phone status. Currently, there > is no SIP server or SIP PBX standard available. Would > anybody give me an idea how can the presence status of > a SIP phone be published to a Presence Server by a SIP > server/PBX or other service? > > Any idea will be appreciated. Thanks in advance. > > Jing > > hisham.khartabil@nokia.com wrote: > > >>There are scenarios where a subscriber has created a filter in a subscription but wishes to replace that filter with another. There were 2 options presented at the interim with me proposing to adopt the 2nd as the solution. >> >>Option 1: remove and add a filter in the same subscription >> >> >> > xmlns:pidf="urn:ietf:params:xml:ns:pidf"> >> >> >> >> //pidf:tuple/pidf:status/pidf:basic >> >> >> >> >>Option 2: Allow a filter to be replaced re-using the same filter id >> >> >> > xmlns:pidf="urn:ietf:params:xml:ns:pidf"> >> >> >> //pidf:tuple/pidf:status/pidf:basic >> >> >> >> >>No one objected to option 2. If there aren't any objections on the mailing list, I will add some clarification text on this issue. >> >>Regards, >>Hisham >> >>_______________________________________________ >>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 > -- 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-bounces@ietf.org Mon Jun 28 18:33:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17955 for ; Mon, 28 Jun 2004 18:33:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4h5-0004hQ-In for simple-archive@ietf.org; Mon, 28 Jun 2004 18:33:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4gC-0004Qy-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:32:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf4ff-00049Y-00; Mon, 28 Jun 2004 18:32:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4SJ-0002eH-4k; Mon, 28 Jun 2004 18:18:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4Bb-0001Md-HN for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:01: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 SAA13112 for ; Mon, 28 Jun 2004 18:01:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Ba-00048h-1k for simple@ietf.org; Mon, 28 Jun 2004 18:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf42W-00027w-00 for simple@ietf.org; Mon, 28 Jun 2004 17:51:49 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3pi-0007NG-00 for simple@ietf.org; Mon, 28 Jun 2004 17:38:34 -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 i5SLc3bq003689; Mon, 28 Jun 2004 16:38:03 -0500 (CDT) Received: from [63.110.3.150] (dhcp150.dfw.dynamicsoft.com [63.110.3.150]) by DYN-TX-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KZRBQJ2W; Mon, 28 Jun 2004 16:38:02 -0500 Message-ID: <40E08FB8.2000505@dynamicsoft.com> Date: Mon, 28 Jun 2004 16:38:00 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom Subject: Re: [Simple] Using MSRP for real time text conversation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: stf267@etsi.org, toip@snowshore.com, hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar: I'm very confused. Why do you want to use MSRP for T.140 text? You don't *need* MSRP to have T.140 conversations. You just carry them like any other real-time streams -- isn't that the point of RFC 2793? INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=- c=IN IP4 pc33.atlanta.com t=0 0 m=text 49172 RTP/AVP 97 a=rtpmap:97 t140/1000 What are you trying to do that cannot be accomplished by this? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 28 18:45:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18774 for ; Mon, 28 Jun 2004 18:45:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4s9-0000B0-ME for simple-archive@ietf.org; Mon, 28 Jun 2004 18:45:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4qr-0007bb-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 18:43:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf4pg-0006yu-00; Mon, 28 Jun 2004 18:42:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4U8-0003xS-HI; Mon, 28 Jun 2004 18:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4L5-0006RX-OC for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15515 for ; Mon, 28 Jun 2004 18:10:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4L4-0006UA-5u for simple@ietf.org; Mon, 28 Jun 2004 18:10:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4JM-0005zU-00 for simple@ietf.org; Mon, 28 Jun 2004 18:09:13 -0400 Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 1Bf4El-0004kl-00 for simple@ietf.org; Mon, 28 Jun 2004 18:04:27 -0400 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040628220357.OPCM24679.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Mon, 28 Jun 2004 17:03:57 -0500 Received: from opwvaditya ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040628220357.IYDK1757.mm-ismta4.bizmailsrvcs.net@opwvaditya>; Mon, 28 Jun 2004 17:03:57 -0500 From: "Aditya Bhasin" To: "'Ben Campbell'" Subject: RE: [Simple] MSRP Boundary header Date: Mon, 28 Jun 2004 15:03:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <40E087B1.2080700@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRdWuvvFx6B0pG+Sa6UxibONJNmUQAAM99A Message-Id: <20040628220357.IYDK1757.mm-ismta4.bizmailsrvcs.net@opwvaditya> Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, Could you explain this a little more. Thx aditya -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Monday, June 28, 2004 2:04 PM To: Murty Dasari Cc: simple@ietf.org Subject: Re: [Simple] MSRP Boundary header The reason is, we added a requirement to be able abort a message without destroying framing for the TCP connection. The boundary approach has that property, content-length does not. Murty Dasari wrote: > Hello, > > > > I've a question about MSRP (based on > draft-ietf-simple-message-sessions-06.txt) "Closing" field. > > > > What is the need for a "Closing" field? > > > > Can't we use "Content-Length" similar to HTTP for determining the > message body length? If this is there for "Continuation-Flag" then > probably we can have another header that indicates continuation status. > Though it might not be lot of work to determine the "closing" tag, it > might be easy for the relays and clients to retrieve the message body > based on content-length header; further, we don't have to add > restrictions on presence of "boundary" in the message body in this case. > > > > This question might have brought-up/answered earlier, but I couldn't > find out from the archives. Appreciate any comments. > > > > Thanks for your time. > > - Murty > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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-bounces@ietf.org Mon Jun 28 19:11:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21796 for ; Mon, 28 Jun 2004 19:11:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5I5-0000Zf-MQ for simple-archive@ietf.org; Mon, 28 Jun 2004 19:11:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5Gu-0000Cf-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 19:10:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf5En-000797-00; Mon, 28 Jun 2004 19:08:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4ut-0003nK-6s; Mon, 28 Jun 2004 18:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4c4-0005h4-On for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:28: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 SAA17775 for ; Mon, 28 Jun 2004 18:28:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4c3-0003Me-Bx for simple@ietf.org; Mon, 28 Jun 2004 18:28:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4b7-00037G-00 for simple@ietf.org; Mon, 28 Jun 2004 18:27:34 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4aY-0002da-00 for simple@ietf.org; Mon, 28 Jun 2004 18:26:58 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SMPxLp009244; Mon, 28 Jun 2004 17:25:59 -0500 Message-ID: <40E09AF7.8020500@dynamicsoft.com> Date: Mon, 28 Jun 2004 17:25:59 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP: updates and re-invites References: <40E084FA.4030007@dynamicsoft.com> <40E097D0.6020401@cisco.com> In-Reply-To: <40E097D0.6020401@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit In the shared connection model, connections are as-needed. By implication, we do not signal connections, we signal sessions. If we signal a session, and the endpoints already have a connection that will serve, they use it. So, if we don't signal the connections in the first place, why would we signal a new connection? Paul Kyzivat wrote: > Ben, > > I think what you describe here is what we discussed at some point, that > should work. But the general wording below leaves me a bit uncertain of > that. Am I right that point below is that if the path is unchanged then > the old connections are reused, while when the path is changed (by > either end) then the offerer establishes a new connection? > > Paul > > Ben Campbell wrote: > >> We have had a lot of discussion on how to handle updated offers in SIP >> updates and re-invites. We had made some proposals back when we >> negotiated connection direction that are not really relevant any more. >> >> The design team spent some time discussing this, and came up with a >> proposal: >> >> Reconnection no longer an issue with connection sharing. TCP >> connection establishment is done on-demand. Therefore we do not need a >> way to signal a desire to establish a new TCP session. >> >> The offerer of a new sdp exchange assumes the role of offerer for all >> purposes, regardless of whether it was the origininal offerer. >> >> An offerer or answer is effectively unchanged if the path does not >> change from the previous version. If either side changes the path, >> then we effectively have a new session. >> >> If offerer does not change anything, answerers can still make changes. >> Answerer must always answer with a currently valid path. These could >> be the same as before the update, or different. >> >> Local policy may choose to re-invite to fix session problems without >> user interaction, or give user a choice. (examples: you get an error >> report to the initial send, a mobile device looses connectivity >> through tunnel, etc.) >> >> I invite everyone who cares to think this through, and make sure we >> are not breaking something important. >> >> Thanks! >> >> 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 From simple-bounces@ietf.org Mon Jun 28 19:17:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22271 for ; Mon, 28 Jun 2004 19:17:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5Ng-0002Oq-7D for simple-archive@ietf.org; Mon, 28 Jun 2004 19:17:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5LK-0001Yy-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 19:15:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf5JB-0000ta-02; Mon, 28 Jun 2004 19:13:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bf55D-0000WK-2z; Mon, 28 Jun 2004 18:58:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4i0-0007vr-Hp; Mon, 28 Jun 2004 18:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4T7-000364-ER for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:19: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 SAA17125 for ; Mon, 28 Jun 2004 18:19:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4T6-0000h2-2l for simple@ietf.org; Mon, 28 Jun 2004 18:19:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4QW-0000Bb-00 for simple@ietf.org; Mon, 28 Jun 2004 18:16:37 -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 1Bf4N7-0006uD-00 for simple@ietf.org; Mon, 28 Jun 2004 18:13:05 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2004 15:16:03 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5SMCX4N000377; Mon, 28 Jun 2004 15:12:33 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT62273; Mon, 28 Jun 2004 18:12:32 -0400 (EDT) Message-ID: <40E097D0.6020401@cisco.com> Date: Mon, 28 Jun 2004 18:12:32 -0400 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 Subject: Re: [Simple] MSRP: updates and re-invites References: <40E084FA.4030007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, I think what you describe here is what we discussed at some point, that should work. But the general wording below leaves me a bit uncertain of that. Am I right that point below is that if the path is unchanged then the old connections are reused, while when the path is changed (by either end) then the offerer establishes a new connection? Paul Ben Campbell wrote: > We have had a lot of discussion on how to handle updated offers in SIP > updates and re-invites. We had made some proposals back when we > negotiated connection direction that are not really relevant any more. > > The design team spent some time discussing this, and came up with a > proposal: > > Reconnection no longer an issue with connection sharing. TCP connection > establishment is done on-demand. Therefore we do not need a way to > signal a desire to establish a new TCP session. > > The offerer of a new sdp exchange assumes the role of offerer for all > purposes, regardless of whether it was the origininal offerer. > > An offerer or answer is effectively unchanged if the path does not > change from the previous version. If either side changes the path, then > we effectively have a new session. > > If offerer does not change anything, answerers can still make changes. > Answerer must always answer with a currently valid path. These could be > the same as before the update, or different. > > Local policy may choose to re-invite to fix session problems without > user interaction, or give user a choice. (examples: you get an error > report to the initial send, a mobile device looses connectivity through > tunnel, etc.) > > I invite everyone who cares to think this through, and make sure we are > not breaking something important. > > Thanks! > > 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 From simple-bounces@ietf.org Mon Jun 28 19:19:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22523 for ; Mon, 28 Jun 2004 19:19:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5Oy-0002bp-1g for simple-archive@ietf.org; Mon, 28 Jun 2004 19:19:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5Mg-00022b-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 19:16:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf5K1-00016w-00; Mon, 28 Jun 2004 19:13:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf54v-0000YV-0e; Mon, 28 Jun 2004 18:58:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4f4-0006yA-3V for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:31: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 SAA17867 for ; Mon, 28 Jun 2004 18:31:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4f2-00048J-NE for simple@ietf.org; Mon, 28 Jun 2004 18:31:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4e3-0003sg-00 for simple@ietf.org; Mon, 28 Jun 2004 18:30:36 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4dc-0003dA-00 for simple@ietf.org; Mon, 28 Jun 2004 18:30:08 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SMTcLp009260; Mon, 28 Jun 2004 17:29:38 -0500 Message-ID: <40E09BD2.2050104@dynamicsoft.com> Date: Mon, 28 Jun 2004 17:29:38 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aditya Bhasin Subject: Re: [Simple] MSRP Boundary header References: <20040628220357.IYDK1757.mm-ismta4.bizmailsrvcs.net@opwvaditya> In-Reply-To: <20040628220357.IYDK1757.mm-ismta4.bizmailsrvcs.net@opwvaditya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit If you use message-length for framing purposes, then once you have sent the message-length value, you have to send that many bytes. If you don't, the peer cannot tell when the current message ends and the next one starts. Once the peer loses track of framing in this way, framing is lost for the entire connection. We could probably fix this with some sort of sync protocol, but that would be more complex than just going to a delimiter approach to framing, which is exactly what the boundary is. Aditya Bhasin wrote: > Ben, > > Could you explain this a little more. > > Thx > > aditya > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Ben Campbell > Sent: Monday, June 28, 2004 2:04 PM > To: Murty Dasari > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > The reason is, we added a requirement to be able abort a message without > destroying framing for the TCP connection. The boundary approach has > that property, content-length does not. > > Murty Dasari wrote: > > >>Hello, >> >> >> >>I've a question about MSRP (based on >>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >> >> >> >>What is the need for a "Closing" field? >> >> >> >>Can't we use "Content-Length" similar to HTTP for determining the >>message body length? If this is there for "Continuation-Flag" then >>probably we can have another header that indicates continuation status. >>Though it might not be lot of work to determine the "closing" tag, it >>might be easy for the relays and clients to retrieve the message body >>based on content-length header; further, we don't have to add >>restrictions on presence of "boundary" in the message body in this case. >> >> >> >>This question might have brought-up/answered earlier, but I couldn't >>find out from the archives. Appreciate any comments. >> >> >> >>Thanks for your time. >> >>- Murty >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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-bounces@ietf.org Mon Jun 28 19:21:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22859 for ; Mon, 28 Jun 2004 19:21:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5RF-0003LB-2K for simple-archive@ietf.org; Mon, 28 Jun 2004 19:21:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5Q9-0002yg-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 19:20:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf5Ok-0002Up-00; Mon, 28 Jun 2004 19:18:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf56l-00019Y-JL; Mon, 28 Jun 2004 19:00:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4qz-0002BF-6W for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:43: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 SAA18567 for ; Mon, 28 Jun 2004 18:43:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4qx-0007cI-NW for simple@ietf.org; Mon, 28 Jun 2004 18:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4pl-0007FC-00 for simple@ietf.org; Mon, 28 Jun 2004 18:42:41 -0400 Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 1Bf4on-0006gs-00 for simple@ietf.org; Mon, 28 Jun 2004 18:41:41 -0400 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040628224112.OYAJ24679.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Mon, 28 Jun 2004 17:41:12 -0500 Received: from opwvaditya ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040628224111.JBNQ1757.mm-ismta4.bizmailsrvcs.net@opwvaditya>; Mon, 28 Jun 2004 17:41:11 -0500 From: "Aditya Bhasin" To: "'Ben Campbell'" Subject: RE: [Simple] MSRP Boundary header Date: Mon, 28 Jun 2004 15:41:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <40E09BD2.2050104@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRdX3gDC1o7OUCHSDmvwxsidlUROgAAQ5ZQ Message-Id: <20040628224111.JBNQ1757.mm-ismta4.bizmailsrvcs.net@opwvaditya> Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit What applications are being targeted for this to be an issue? The size of the content will have to be extremely large and the application pretty close to a streaming application to be able to insert an ending boundary delimiter. Sorry late to the discussions and only trying to understand what is driving this requirement. thx -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Monday, June 28, 2004 3:30 PM To: Aditya Bhasin Cc: simple@ietf.org Subject: Re: [Simple] MSRP Boundary header If you use message-length for framing purposes, then once you have sent the message-length value, you have to send that many bytes. If you don't, the peer cannot tell when the current message ends and the next one starts. Once the peer loses track of framing in this way, framing is lost for the entire connection. We could probably fix this with some sort of sync protocol, but that would be more complex than just going to a delimiter approach to framing, which is exactly what the boundary is. Aditya Bhasin wrote: > Ben, > > Could you explain this a little more. > > Thx > > aditya > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of > Ben Campbell > Sent: Monday, June 28, 2004 2:04 PM > To: Murty Dasari > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > The reason is, we added a requirement to be able abort a message without > destroying framing for the TCP connection. The boundary approach has > that property, content-length does not. > > Murty Dasari wrote: > > >>Hello, >> >> >> >>I've a question about MSRP (based on >>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >> >> >> >>What is the need for a "Closing" field? >> >> >> >>Can't we use "Content-Length" similar to HTTP for determining the >>message body length? If this is there for "Continuation-Flag" then >>probably we can have another header that indicates continuation status. >>Though it might not be lot of work to determine the "closing" tag, it >>might be easy for the relays and clients to retrieve the message body >>based on content-length header; further, we don't have to add >>restrictions on presence of "boundary" in the message body in this case. >> >> >> >>This question might have brought-up/answered earlier, but I couldn't >>find out from the archives. Appreciate any comments. >> >> >> >>Thanks for your time. >> >>- Murty >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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-bounces@ietf.org Mon Jun 28 19:25:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23213 for ; Mon, 28 Jun 2004 19:25:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5VX-0004qR-9A for simple-archive@ietf.org; Mon, 28 Jun 2004 19:25:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5Uc-0004Wu-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 19:24:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf5Tf-00040y-00; Mon, 28 Jun 2004 19:23:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf5GC-0004Nf-NC; Mon, 28 Jun 2004 19:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4wp-0004ou-FR for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:49:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19207 for ; Mon, 28 Jun 2004 18:49:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4wo-0001qO-33 for simple@ietf.org; Mon, 28 Jun 2004 18:49:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4vT-0001RB-00 for simple@ietf.org; Mon, 28 Jun 2004 18:48:36 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4uJ-0000mx-00 for simple@ietf.org; Mon, 28 Jun 2004 18:47:23 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5SMkrLp009349; Mon, 28 Jun 2004 17:46:53 -0500 Message-ID: <40E09FDD.1020505@dynamicsoft.com> Date: Mon, 28 Jun 2004 17:46:53 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aditya Bhasin Subject: Re: [Simple] MSRP Boundary header References: <20040628224111.JBNQ1757.mm-ismta4.bizmailsrvcs.net@opwvaditya> In-Reply-To: <20040628224111.JBNQ1757.mm-ismta4.bizmailsrvcs.net@opwvaditya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The ability to handle large content has been a generally accepted requirement. The entire chunking mechanism is there due to this requirement. I do not understand what you mean by "being close to the application". There a a number of ways an application could talk to the MSRP layer. For an absurdly trivial example, you could simply pipe output from an app, and have MSRP recognize the end-of-file. Aditya Bhasin wrote: > What applications are being targeted for this to be an issue? > > The size of the content will have to be extremely large and the application > pretty close to a streaming application to be able to insert an ending > boundary delimiter. > > Sorry late to the discussions and only trying to understand what is driving > this requirement. > > thx > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, June 28, 2004 3:30 PM > To: Aditya Bhasin > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > If you use message-length for framing purposes, then once you have sent > the message-length value, you have to send that many bytes. If you > don't, the peer cannot tell when the current message ends and the next > one starts. Once the peer loses track of framing in this way, framing is > lost for the entire connection. > > We could probably fix this with some sort of sync protocol, but that > would be more complex than just going to a delimiter approach to > framing, which is exactly what the boundary is. > > > > Aditya Bhasin wrote: > > >>Ben, >> >>Could you explain this a little more. >> >>Thx >> >>aditya >> >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > > Of > >>Ben Campbell >>Sent: Monday, June 28, 2004 2:04 PM >>To: Murty Dasari >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP Boundary header >> >>The reason is, we added a requirement to be able abort a message without >>destroying framing for the TCP connection. The boundary approach has >>that property, content-length does not. >> >>Murty Dasari wrote: >> >> >> >>>Hello, >>> >>> >>> >>>I've a question about MSRP (based on >>>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >>> >>> >>> >>>What is the need for a "Closing" field? >>> >>> >>> >>>Can't we use "Content-Length" similar to HTTP for determining the >>>message body length? If this is there for "Continuation-Flag" then >>>probably we can have another header that indicates continuation status. >>>Though it might not be lot of work to determine the "closing" tag, it >>>might be easy for the relays and clients to retrieve the message body >>>based on content-length header; further, we don't have to add >>>restrictions on presence of "boundary" in the message body in this case. >>> >>> >>> >>>This question might have brought-up/answered earlier, but I couldn't >>>find out from the archives. Appreciate any comments. >>> >>> >>> >>>Thanks for your time. >>> >>>- Murty >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>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-bounces@ietf.org Mon Jun 28 19:27:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23387 for ; Mon, 28 Jun 2004 19:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5XL-0005Si-VW for simple-archive@ietf.org; Mon, 28 Jun 2004 19:27:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5WX-0005BC-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 19:26:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf5Vk-0004o1-00; Mon, 28 Jun 2004 19:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf5HJ-0004tA-VM; Mon, 28 Jun 2004 19:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf51I-0006jW-OT for simple@megatron.ietf.org; Mon, 28 Jun 2004 18:54: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 SAA19678 for ; Mon, 28 Jun 2004 18:54:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf51H-0003PQ-BK for simple@ietf.org; Mon, 28 Jun 2004 18:54:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4zp-0002w1-00 for simple@ietf.org; Mon, 28 Jun 2004 18:53:06 -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 1Bf4yX-0002EW-00 for simple@ietf.org; Mon, 28 Jun 2004 18:51:46 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2004 15:54:43 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i5SMpDZr000444; Mon, 28 Jun 2004 15:51:14 -0700 (PDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJT64453; Mon, 28 Jun 2004 18:51:13 -0400 (EDT) Message-ID: <40E0A0E1.4060603@cisco.com> Date: Mon, 28 Jun 2004 18:51:13 -0400 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 Subject: Re: [Simple] MSRP: updates and re-invites References: <40E084FA.4030007@dynamicsoft.com> <40E097D0.6020401@cisco.com> <40E09AF7.8020500@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > In the shared connection model, connections are as-needed. By > implication, we do not signal connections, we signal sessions. If we > signal a session, and the endpoints already have a connection that will > serve, they use it. > > So, if we don't signal the connections in the first place, why would we > signal a new connection? Unless I missed a change somewhere, connections *at the endpoints* are not entirely as-needed. In particular, if a connection has gone away but is still needed it cannot just be made again. But I agree that the need to do that can be defined away, by saying that loss of the connection implies loss of the session, so that a new session must be requested. I think this is what you mean, and if so that is fine. I just want to be sure. Paul > Paul Kyzivat wrote: > >> Ben, >> >> I think what you describe here is what we discussed at some point, >> that should work. But the general wording below leaves me a bit >> uncertain of that. Am I right that point below is that if the path is >> unchanged then the old connections are reused, while when the path is >> changed (by either end) then the offerer establishes a new connection? >> >> Paul >> >> Ben Campbell wrote: >> >>> We have had a lot of discussion on how to handle updated offers in >>> SIP updates and re-invites. We had made some proposals back when we >>> negotiated connection direction that are not really relevant any more. >>> >>> The design team spent some time discussing this, and came up with a >>> proposal: >>> >>> Reconnection no longer an issue with connection sharing. TCP >>> connection establishment is done on-demand. Therefore we do not need >>> a way to signal a desire to establish a new TCP session. >>> >>> The offerer of a new sdp exchange assumes the role of offerer for all >>> purposes, regardless of whether it was the origininal offerer. >>> >>> An offerer or answer is effectively unchanged if the path does not >>> change from the previous version. If either side changes the path, >>> then we effectively have a new session. >>> >>> If offerer does not change anything, answerers can still make >>> changes. Answerer must always answer with a currently valid path. >>> These could be the same as before the update, or different. >>> >>> Local policy may choose to re-invite to fix session problems without >>> user interaction, or give user a choice. (examples: you get an error >>> report to the initial send, a mobile device looses connectivity >>> through tunnel, etc.) >>> >>> I invite everyone who cares to think this through, and make sure we >>> are not breaking something important. >>> >>> Thanks! >>> >>> 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 From simple-bounces@ietf.org Mon Jun 28 21:23:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29094 for ; Mon, 28 Jun 2004 21:23:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf7LX-0005ef-DM for simple-archive@ietf.org; Mon, 28 Jun 2004 21:23:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf7Kd-0005Pu-00 for simple-archive@ietf.org; Mon, 28 Jun 2004 21:22:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bf7KA-0005As-00; Mon, 28 Jun 2004 21:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf7HQ-0000kq-KM; Mon, 28 Jun 2004 21:19:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf7Dx-0000VT-PT for simple@megatron.ietf.org; Mon, 28 Jun 2004 21:15: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 VAA28878 for ; Mon, 28 Jun 2004 21:15:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf7Dw-0003fS-4F for simple@ietf.org; Mon, 28 Jun 2004 21:15:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf7D2-0003PF-00 for simple@ietf.org; Mon, 28 Jun 2004 21:14:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Bf7CM-00038j-00 for simple@ietf.org; Mon, 28 Jun 2004 21:14:10 -0400 Received: from razor.cs.columbia.edu (IDENT:LMIPJev8/36Nm11N8cQf8T7yzrZiRDQb@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5T1E5fq006995 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 28 Jun 2004 21:14:05 -0400 (EDT) Received: from cs.columbia.edu (IDENT:G20pIW9Bs1ars4k2raTJ+PmgWsk71ZHL@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i5T1E4jd017520; Mon, 28 Jun 2004 21:14:04 -0400 Message-ID: <40E0C261.3010003@cs.columbia.edu> Date: Mon, 28 Jun 2004 21:14:09 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] How to get SIP phone presence info References: <2038BCC78B1AD641891A0D1AE133DBB701797B9D@esebe019.ntc.nokia.com> <40DAE695.818391E1@alcatel.com> <40E08E4B.8060603@dynamicsoft.com> In-Reply-To: <40E08E4B.8060603@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.6.28.105365 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Cc: Jing Qian , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > There are a few possibilities: > > 1. There is an RPID extension for indicating whether or not a user is on > the phone or not. The IP PBX can send a PUBLISH message for the AOR of > the user, including a presence document indicating this information. Slight amplification: this is one of the standard RPID activity tokens ("on-the-phone"), not an RPID extension. > > 2. I had submitted, quite some time back, a proposal for adding phone > status information to pidf: > > http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt > > There was pushback to all of this in pidf, and these days, I am inclined > to agree. I think that phone status is really a separate event package. > I have in mind to submit an update to this document defining a separate > event package, but there is nothing right now. > > 3. The dialog event package and reg event package, when put together, > tell you a lot about the status of a SIP phone. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 01:59:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09429 for ; Tue, 29 Jun 2004 01:59:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfBeu-0001rd-AB for simple-archive@ietf.org; Tue, 29 Jun 2004 01:59:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfBe1-0001aT-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 01:59:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfBdb-0001JU-00; Tue, 29 Jun 2004 01:58:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfBan-0006mg-Am; Tue, 29 Jun 2004 01:55:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfBY9-0006a6-Fv for simple@megatron.ietf.org; Tue, 29 Jun 2004 01:52: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 BAA09020 for ; Tue, 29 Jun 2004 01:52:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfBY7-0007Z6-7c for simple@ietf.org; Tue, 29 Jun 2004 01:52:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfBX4-000797-00 for simple@ietf.org; Tue, 29 Jun 2004 01:51:51 -0400 Received: from av3-1-sn3.vrr.skanova.net ([81.228.9.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfBVb-0006XS-00 for simple@ietf.org; Tue, 29 Jun 2004 01:50:19 -0400 Received: by av3-1-sn3.vrr.skanova.net (Postfix, from userid 502) id C20EB37EA6; Tue, 29 Jun 2004 07:49:49 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B2F0437E52; Tue, 29 Jun 2004 07:49:49 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 632E738003; Tue, 29 Jun 2004 07:49:49 +0200 (CEST) From: "Gunnar Hellstrom" To: "Adam Roach" Subject: RE: [Simple] Using MSRP for real time text conversation Date: Tue, 29 Jun 2004 07:49:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40E08FB8.2000505@dynamicsoft.com> Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, toip@snowshore.com, hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Adam, Sorry for the confusion. Yes, we have what we need for real time text in RTP with text/t140. The discussion was started by a suggestion that use of MRSP for real time= text would cause a better uptake by the industry. I do not know how that suggestion can be evaluated. Text/t140 is so easy = to do, so it is merely the understanding of the opportunities that is needed. -------------------------- A lot has been said about good behaviour in the Internet in the thread, p= ossibly indicating that using real time text would not be good behaviour in the I= nternet. I think it is. With MRSP we saw that we would have a load of about 6 kbit/s when = actively typing, and with text/140 it will be around 2.5 kbit/s when actively typing. Occa= sional jitter of 1 second is of no major concern. At severe congestion, some hampered conv= ersation could continue even if buffering was increased to 5 seconds, and that way of ha= ndling congestion is now in rfc2793bis-07 that was published yesterday. So, with this reasonable behaviour compared to the real time companions v= oice and video, who gladly grab 40 kbit/s or more and require to have an even flow, I thi= nk text behaves very well. I hope all are prepared to include it in real time conversatio= nal designs in order to make conversational services a bit more usable for all. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: Adam Roach [mailto:adam@dynamicsoft.com] >Sent: Monday, June 28, 2004 11:38 PM >To: Gunnar Hellstrom >Cc: hisham.khartabil@nokia.com; stf267@etsi.org; simple@ietf.org; >toip@snowshore.com >Subject: Re: [Simple] Using MSRP for real time text conversation > > >Gunnar: > >I'm very confused. Why do you want to use MSRP for T.140 text? You don't >*need* MSRP to have T.140 conversations. You just carry them like any >other real-time streams -- isn't that the point of RFC 2793? > > INVITE sip:bob@biloxi.com SIP/2.0 > Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Max-Forwards: 70 > Date: Thu, 21 Feb 2002 13:02:03 GMT > Contact: > Content-Type: application/sdp > Content-Length: 147 > > v=3D0 > o=3DUserA 2890844526 2890844526 IN IP4 here.com > s=3D- > c=3DIN IP4 pc33.atlanta.com > t=3D0 0 > m=3Dtext 49172 RTP/AVP 97 > a=3Drtpmap:97 t140/1000 > > >What are you trying to do that cannot be accomplished by this? > >/a > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 03:41:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28439 for ; Tue, 29 Jun 2004 03:41:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfDFY-00013V-2B for simple-archive@ietf.org; Tue, 29 Jun 2004 03:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfDEb-0000mn-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 03:40:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfDDm-0000FZ-00; Tue, 29 Jun 2004 03:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfD9y-00071G-6K; Tue, 29 Jun 2004 03:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfD52-0006dj-AC for simple@megatron.ietf.org; Tue, 29 Jun 2004 03:31: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 DAA28151 for ; Tue, 29 Jun 2004 03:30:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfD50-0005mP-5r for simple@ietf.org; Tue, 29 Jun 2004 03:30:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfD43-0005VI-00 for simple@ietf.org; Tue, 29 Jun 2004 03:29:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BfD3g-0005Dp-00 for simple@ietf.org; Tue, 29 Jun 2004 03:29:36 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T7TWN27624; Tue, 29 Jun 2004 10:29:32 +0300 (EET DST) X-Scanned: Tue, 29 Jun 2004 10:28:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5T7Ss3i010638; Tue, 29 Jun 2004 10:28:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00JqQN5E; Tue, 29 Jun 2004 10:28:52 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T7SoH10565; Tue, 29 Jun 2004 10:28:50 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Jun 2004 10:28:48 +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] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Tue, 29 Jun 2004 10:28:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CD5@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 Thread-Index: AcRdQHrA8aADYi1LRGSb5Sxt0U71zgAafNZQ To: X-OriginalArrivalTime: 29 Jun 2004 07:28:48.0745 (UTC) FILETIME=[B8156590:01C45DAA] Content-Transfer-Encoding: quoted-printable Cc: toip@snowshore.com, gunnar.hellstrom@omnitor.se, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28.June.2004 21:48 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: gunnar.hellstrom@omnitor.se; toip@snowshore.com; simple@ietf.org > Subject: Re: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140 > was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 >=20 > >=20 > > I don't understand why this is MSRP's problem at all.=20 > > MRP is built for the reason of instant message conversations, > > as the draft cleary states. If MSRP does not meet you needs,=20 > > you are free to implement any other text media protocol you=20 > > choose, but I do not believe that MSRP is the right place=20 > > to indicate this. > >=20 >=20 > Ok, let's back up a step. I don't think anyone is suggesting=20 > that MSRP=20 > is currently expected to do real-time text. >=20 > We have a set of valid requirements for real-time text. What we're=20 > discussing is how best to meet those requirements. >=20 >=20 > I'm asking: >=20 > 1) Could a congestion-safe protocol like MSRP be adapted to meet the=20 > requirements of real-time text? >=20 > 2) If so, would this be better than using RTP? (and remember,=20 > "better"=20 > is a broad and subjective). >=20 > 3) If so, would the people who are working on MSRP be interested in=20 > extending its requirement set to address the requirements of=20 > real time text? >=20 > I believe Hisham is indicating above that he feels that MSRP=20 > is either=20 > an innapropriate starting point, or that as one of the people=20 > working on=20 > MSRP he's not interested in adapting it to meet the requirements of=20 > real-time text. Do I have that right, Hisham? Speaking as a contributor to MSRP, I am not interested at this point in = time. Speaking as a chair, I believe it is out of scope of the SIMPLE WG. Thanks, Hisham >=20 > -- > Dean >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 04:07:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00031 for ; Tue, 29 Jun 2004 04:07:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfDeT-0000zI-OO for simple-archive@ietf.org; Tue, 29 Jun 2004 04:07:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfDcG-0000MY-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 04:05:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfDaL-0007Rn-00; Tue, 29 Jun 2004 04:03:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfDRK-00030c-Te; Tue, 29 Jun 2004 03:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfDMe-0008Nv-Nm; Tue, 29 Jun 2004 03:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfDGi-0007qi-Jl for simple@megatron.ietf.org; Tue, 29 Jun 2004 03: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 DAA28477 for ; Tue, 29 Jun 2004 03:43:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfDGf-0001Lv-5d for simple@ietf.org; Tue, 29 Jun 2004 03:43:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfDFe-00014N-00 for simple@ietf.org; Tue, 29 Jun 2004 03:41:58 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BfDFI-0000nY-00 for simple@ietf.org; Tue, 29 Jun 2004 03:41:36 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T7fZ207771; Tue, 29 Jun 2004 10:41:35 +0300 (EET DST) X-Scanned: Tue, 29 Jun 2004 10:41:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5T7fQLq023014; Tue, 29 Jun 2004 10:41:26 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00jXjn2K; Tue, 29 Jun 2004 10:41:26 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T7fQH16782; Tue, 29 Jun 2004 10:41:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Jun 2004 10:41:26 +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: Surpression of duplicates Date: Tue, 29 Jun 2004 10:41:24 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CD7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Surpression of duplicates Thread-Index: AcRdWfFaxzoDjxzbS3KZwDlaGRbVQAAUgWmg To: , X-OriginalArrivalTime: 29 Jun 2004 07:41:26.0224 (UTC) FILETIME=[7B938500:01C45DAC] Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Ben Campbell > Sent: 28.June.2004 23:36 > To: Simple WG > Subject: [Simple] MSRP: Surpression of duplicates >=20 >=20 > The working group has gone round and round on whether (and how) we=20 > handle worry about the surpression of duplicate messages, in=20 > situations=20 > where a failure occurs, and the sender chooses to re-send=20 > content on a=20 > new session. >=20 > Since we have introduced the concept of a MessageID, this=20 > becomes fairly=20 > easy to accomplish. If we specify the MessageID to be=20 > globally unique,=20 > or even just very likely to re-occur in a relatively short=20 > time period,=20 > then the receive can simply watch for duplicate messageIDs. The=20 > receiver's action upon receiving a duplicate would be entirely up to=20 > local policy (although simply displaying the duplicate to the user=20 > without any warning of duplication would be a bad choice.) >=20 > This approach only works for detecting whole-content=20 > duplication, rather=20 > than chunk duplication. We recommend that chunks of a given=20 > message not=20 > be spread across more than one session. I don't like this recommendation. If I'm sending you a 5GB file in = chunks and the session breaks, then I would like to continue where I = left off. But I guess it doesn't necessarily have to be the same message = ID. /Hisham > Within any given session, the=20 > chunking mechanism already provides a way to notice=20 > duplication--you can=20 > watch for byte-range overlaps. >=20 > If there are no subtantive objections to the approach, the next draft=20 > version will describe the details. >=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-bounces@ietf.org Tue Jun 29 04:08:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00126 for ; Tue, 29 Jun 2004 04:08:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfDex-0001GG-Uk for simple-archive@ietf.org; Tue, 29 Jun 2004 04:08:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfDcl-0000WZ-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 04:05:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfDaW-0007TU-00; Tue, 29 Jun 2004 04:03:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfDMk-0002rt-Ko; Tue, 29 Jun 2004 03:49:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfDJM-00088o-4N; Tue, 29 Jun 2004 03:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfDAo-00076A-0P for simple@megatron.ietf.org; Tue, 29 Jun 2004 03:36:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28272 for ; Tue, 29 Jun 2004 03:36:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfDAl-0007Qo-Pu for simple@ietf.org; Tue, 29 Jun 2004 03:36:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfD9i-00078I-00 for simple@ietf.org; Tue, 29 Jun 2004 03:35:51 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BfD8d-0006bf-00 for simple@ietf.org; Tue, 29 Jun 2004 03:34:44 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T7YVJ06836; Tue, 29 Jun 2004 10:34:32 +0300 (EET DST) X-Scanned: Tue, 29 Jun 2004 10:34:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5T7YOgg025902; Tue, 29 Jun 2004 10:34:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00PuTw7u; Tue, 29 Jun 2004 10:34:22 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T7YDH15253; Tue, 29 Jun 2004 10:34:13 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Jun 2004 10:34:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Jun 2004 10:34:08 +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: Miscellaneous REPORT issues Date: Tue, 29 Jun 2004 10:34:06 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CD6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Miscellaneous REPORT issues Thread-Index: AcRdWZYghIfUd62DTkuBDQrZVrrbxgAUaiIw To: , X-OriginalArrivalTime: 29 Jun 2004 07:34:08.0930 (UTC) FILETIME=[76EDC020:01C45DAB] Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, rohan@cisco.com, adam@dynamicsoft.com, cboulton@ubiquity.com, rsparks@dynamicsoft.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Ben Campbell > Sent: 28.June.2004 23:21 > To: Simple WG > Cc: Cullen Jennings; Rohan Mahy; Adam Roach; Khartabil Hisham > (Nokia-TP-MSW/Helsinki); Robert Sparks; Chris Boulton > Subject: [Simple] MSRP: Miscellaneous REPORT issues >=20 >=20 > This note contains a few additional DSN issues, and the directions=20 > proposed by the design team. >=20 > 1) We have had comments that the DSN file format may be two=20 > heavy weight. >=20 > We propose that DSN bodies become optional in REPORT methods.=20 > We would=20 > make it possible to convey basic information in header fields in the=20 > REPORT method. A DSN body would become optional for when the=20 > reporting=20 > device desires a more expressive approach, at its discretion. >=20 > We propose to add REPORT method header fields for MessageID=20 > and Status.=20 > The MessageID header would corelate with the MessageID of the=20 > original=20 > content. The status field will include a "scope" token, a=20 > status token,=20 > and a human readable string. Just so people understand why TransactionID is not included, are DSN = REPORTs scoped per message (i.e. all the chunks) for per transaction = (chunck). Thanks, Hisham >=20 > Actual DSN payloads are optional. Positive REPORTs MAY contain a=20 > payload. Negative reports SHOULD contain a DSN payload. >=20 > 2) Handling REPORTs that occur after a session is complete.=20 > Relays are=20 > not aware of the precise timing of the opening and closing of=20 > a session,=20 > so they cannot be prevented from originating REPORTS for=20 > sessions that=20 > have been closed. >=20 > We propose to specify that a relay SHOULD NOT attempt to generate a=20 > report if it has reason to believe it will not be delivered.=20 > We do not=20 > define how it might have such reason, but will give a couple=20 > of examples=20 > (perhaps its URL has expired, or it has out-of-band knowledge.)=20 > Endpoints MAY accept REPORT requests after a session is over, but are=20 > not required to take any action to make it easy for someone=20 > to send one.=20 > Endpoints SHOULD NOT send DSN for expired sessions. >=20 > There was also a question about how to handle the situation where you=20 > have requested positive reports, but We do not state any normative=20 > requirements about waiting for REPORT requests to arrive=20 > before ending a=20 > session, but will discuss choices and their concequences. >=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-bounces@ietf.org Tue Jun 29 08:24:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15201 for ; Tue, 29 Jun 2004 08:24:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfHek-0003YJ-Dk for simple-archive@ietf.org; Tue, 29 Jun 2004 08:24:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfHdn-0003FB-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 08:23:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfHcv-0002dI-00; Tue, 29 Jun 2004 08:22:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfHUe-0004Tk-Om; Tue, 29 Jun 2004 08:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfHQZ-0003aC-Sz for simple@megatron.ietf.org; Tue, 29 Jun 2004 08:09: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 IAA14514 for ; Tue, 29 Jun 2004 08:09:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfHQZ-00079J-9P for simple@ietf.org; Tue, 29 Jun 2004 08:09:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfHPe-0006nv-00 for simple@ietf.org; Tue, 29 Jun 2004 08:08:35 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1BfHOo-0006T3-00 for simple@ietf.org; Tue, 29 Jun 2004 08:07:42 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id OAA83859 for ; Tue, 29 Jun 2004 14:11:46 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma083671; Tue, 29 Jun 04 14:10:23 +0200 Received: from IVD-Message_Server by gw-server.viataal.nl with Novell_GroupWise; Tue, 29 Jun 2004 14:06:17 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Tue, 29 Jun 2004 14:05:49 +0200 From: "A vWijk" To: , Subject: RE: [Simple] Using MSRP for real time text conversation Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, toip@snowshore.com, hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable So, the answer to that "discussion" whether it it relevant to look at MRSP to = use for real-time character per character text is actually unfavourable. RFC 2793 gives a better and less bandwidth consuming solution which is = ALREADY implemented! Even though as Gunnar correctly pointed out, interactive text's bandwidth = usage is so low compared to the audio and video streams To avoid confusion. Just forget MRSP for real-time interactive text usage. Just focus on adding the option to IM to switch between IM per message and = real-time chat depending when the user desires/needs it. And switch back = to IM mode. greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> "Gunnar Hellstrom" 06/29/04 07:49am >>> Adam, Sorry for the confusion. Yes, we have what we need for real time text in RTP with text/t140. The discussion was started by a suggestion that use of MRSP for real time = text would cause a better uptake by the industry. I do not know how that suggestion can be evaluated. Text/t140 is so easy = to do, so it is merely the understanding of the opportunities that is needed. -------------------------- A lot has been said about good behaviour in the Internet in the thread, = possibly indicating that using real time text would not be good behaviour in the = Internet. I think it is. With MRSP we saw that we would have a load of about 6 kbit/s when = actively typing, and with text/140 it will be around 2.5 kbit/s when actively typing. = Occasional jitter of 1 second is of no major concern. At severe congestion, some hampered = conversation could continue even if buffering was increased to 5 seconds, and that way of = handling congestion is now in rfc2793bis-07 that was published yesterday. So, with this reasonable behaviour compared to the real time companions = voice and video, who gladly grab 40 kbit/s or more and require to have an even flow, I = think text behaves very well. I hope all are prepared to include it in real time conversationa= l designs in order to make conversational services a bit more usable for all. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se=20 Gunnar.Hellstrom@Omnitor.se=20 -------------------------------------------- >-----Original Message----- >From: Adam Roach [mailto:adam@dynamicsoft.com]=20 >Sent: Monday, June 28, 2004 11:38 PM >To: Gunnar Hellstrom >Cc: hisham.khartabil@nokia.com; stf267@etsi.org; simple@ietf.org; >toip@snowshore.com=20 >Subject: Re: [Simple] Using MSRP for real time text conversation > > >Gunnar: > >I'm very confused. Why do you want to use MSRP for T.140 text? You don't >*need* MSRP to have T.140 conversations. You just carry them like any >other real-time streams -- isn't that the point of RFC 2793? > > INVITE sip:bob@biloxi.com SIP/2.0 > Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Max-Forwards: 70 > Date: Thu, 21 Feb 2002 13:02:03 GMT > Contact: > Content-Type: application/sdp > Content-Length: 147 > > v=3D0 > o=3DUserA 2890844526 2890844526 IN IP4 here.com > s=3D- > c=3DIN IP4 pc33.atlanta.com > t=3D0 0 > m=3Dtext 49172 RTP/AVP 97 > a=3Drtpmap:97 t140/1000 > > >What are you trying to do that cannot be accomplished by this? > >/a > > _______________________________________________ Simple mailing list Simple@ietf.org=20 https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 12:01:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28569 for ; Tue, 29 Jun 2004 12:01:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfL3A-00078K-1D for simple-archive@ietf.org; Tue, 29 Jun 2004 12:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfL2R-0006mH-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 12:00:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfL1g-0006Ky-00; Tue, 29 Jun 2004 12:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKx8-0006i8-Ag; Tue, 29 Jun 2004 11:55:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKpX-0005p5-8g for simple@megatron.ietf.org; Tue, 29 Jun 2004 11: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 LAA27650 for ; Tue, 29 Jun 2004 11:47:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfKpW-00028i-94 for simple@ietf.org; Tue, 29 Jun 2004 11:47:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfKoU-0001jm-00 for simple@ietf.org; Tue, 29 Jun 2004 11:46:27 -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 1BfKnM-0001K0-00 for simple@ietf.org; Tue, 29 Jun 2004 11:45:16 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212] (may be forged)) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i5TFjBq0007610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2004 10:45:13 -0500 Message-ID: <40E18E80.2060105@softarmor.com> Date: Tue, 29 Jun 2004 10:45:04 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple] Using MSRP for real time text conversation References: <40E08FB8.2000505@dynamicsoft.com> In-Reply-To: <40E08FB8.2000505@dynamicsoft.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: toip@snowshore.com, Gunnar Hellstrom , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Gunnar: > > I'm very confused. Why do you want to use MSRP for T.140 text? You don't > *need* MSRP to have T.140 conversations. You just carry them like any > other real-time streams -- isn't that the point of RFC 2793? > Darn these cross-list discussions. You and Hisham seem to have missed the first forty messages in this thread, and reacted with justifiable surprise. Recap, for those who missed the first season of our serial drama: Gunnar does NOT "want" to use MSRP -- he proposed using T.140 exactly as you discussed it above. He also wants real-time text in every phone and messaging device produced, for 100% availability, a goal that I find agreeable. However, I don't want to use T.140. Emulating reliability by requiring multiple transmissions of every character without regard for real network conditions is a horrible violation of the principles of RFC2914. So, I raised the question: Could we use a reliable and 2914-compliant protocol like MSRP to meet the needs of real-time text? We are now discussing this possibility, using MSRP as the baseline. Open questions: 1) Would the user experience be acceptable? 2) What is the bandwidth required, relative to T.140? 3) How much change would this imply for MSRP? 4) How will this affect the widepsread availability of real-time text? Cullen has proposed that if this is simple as a check-box in the GUI of every MSRP client, then EVERYBODY has eal-time text capability. 5) What are the pros and cons of the various approaches with respect to firewalls and NATs? Clearly TCP has some advantages, and MSRP has relays, but TURN and STUN give us some existing infrastructure for T.140. 6) is there a sufficient perception of value in the community to justify adding this sort of function to MSRP, or would yet another protocol be required? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 12:32:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00314 for ; Tue, 29 Jun 2004 12:32:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfLX0-0002XE-JF for simple-archive@ietf.org; Tue, 29 Jun 2004 12:32:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfLW5-0002CB-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 12:31:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfLVT-0001pT-00; Tue, 29 Jun 2004 12:30:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfLLo-00034M-4z; Tue, 29 Jun 2004 12:20:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfL6q-00084A-Pv for simple@megatron.ietf.org; Tue, 29 Jun 2004 12:05: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 MAA28708 for ; Tue, 29 Jun 2004 12:05:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfL6p-0000gI-T4 for simple@ietf.org; Tue, 29 Jun 2004 12:05:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfL5t-0000Lc-00 for simple@ietf.org; Tue, 29 Jun 2004 12:04:26 -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 1BfL5J-00000v-00 for simple@ietf.org; Tue, 29 Jun 2004 12:03:49 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212] (may be forged)) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i5TG3hq0007684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2004 11:03:45 -0500 Message-ID: <40E192DA.6050008@softarmor.com> Date: Tue, 29 Jun 2004 11:03:38 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom Subject: Re: [Simple] Using MSRP for real time text conversation References: In-Reply-To: X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: stf267@etsi.org, hisham.khartabil@nokia.com, toip@snowshore.com, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > A lot has been said about good behaviour in the Internet in the thread, possibly > indicating that using real time text would not be good behaviour in the Internet. I think > it is. With MRSP we saw that we would have a load of about 6 kbit/s when actively typing, > and with text/140 it will be around 2.5 kbit/s when actively typing. Occasional jitter of > 1 second is of no major concern. At severe congestion, some hampered conversation could > continue even if buffering was increased to 5 seconds, and that way of handling congestion > is now in rfc2793bis-07 that was published yesterday. > > So, with this reasonable behaviour compared to the real time companions voice and video, > who gladly grab 40 kbit/s or more and require to have an even flow, I think text behaves > very well. I hope all are prepared to include it in real time conversational designs in > order to make conversational services a bit more usable for all. > > Being a good citizen of the Internet is not simply a matter of using less bandwidth. It requires the ability to react to degrading network conditions by deliberately reducing one's impact on the network as those conditions degrade. T.140 sometimes reacts (if at all -- it might just degrade the user experience by losing data) the other way -- by sending MORE packets and increasing the effective load as the network decays. This is the sort of behavior that drives "congestion collapse" events in networks. True, the latest 2793bis also talks about backing off the inter-character timer (while requiring continued redundant transmissions), but this doesn't produce much leverage for congestion control. It also doesn't specify when this back off should happen. It certainly doesn't mandate congestion-safe behavior. I quote: If the application needs to reduce its sending rate, it SHOULD NOT reduce the number of redundancy levels below the default amount specified in section 4. Instead, the following actions are RECOMMENDED in order of priority: - Increase the shortest time between transmissions described in section 5.1 from the recommended 300 ms to 500 ms that is the highest value allowable according to T.140. - Limit the maximum rate of characters transmitted. - Increase the shortest time between transmissions to a higher value, not higher than 5 seconds. This will cause unpleasant delays in transmission, beyond what is allowed according to T.140, but text will still be conveyed in the session with some usability. We know from our experience in SIP that trying to invent congestion management mechanisms that are more application-optimal than TCP is a tricky business. Other possible solutions include using DCCP instead of UDP as the underlying transport for real-time text. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 12:53:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01820 for ; Tue, 29 Jun 2004 12:53:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfLrS-0002LG-VK for simple-archive@ietf.org; Tue, 29 Jun 2004 12:53:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfLpL-0001Ur-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 12:51:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfLnI-0000fG-00; Tue, 29 Jun 2004 12:49:16 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfLXr-0005tc-7g; Tue, 29 Jun 2004 12:33:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfLP8-0003PI-JQ; Tue, 29 Jun 2004 12:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfLKW-0002nW-VK for simple@megatron.ietf.org; Tue, 29 Jun 2004 12:19: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 MAA29448 for ; Tue, 29 Jun 2004 12:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfLKV-0005kz-Rf for simple@ietf.org; Tue, 29 Jun 2004 12:19:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfLJU-0005O6-00 for simple@ietf.org; Tue, 29 Jun 2004 12:18:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BfLIp-0004ii-00 for simple@ietf.org; Tue, 29 Jun 2004 12:17:47 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2004 12:24:43 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5TGH0Gs018300; Tue, 29 Jun 2004 12:17:00 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJU07788; Tue, 29 Jun 2004 12:16:58 -0400 (EDT) Message-ID: <40E195FA.50605@cisco.com> Date: Tue, 29 Jun 2004 12:16:58 -0400 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: Dean Willis Subject: Re: [Simple] Using MSRP for real time text conversation References: <40E08FB8.2000505@dynamicsoft.com> <40E18E80.2060105@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: toip@snowshore.com, Adam Roach , Gunnar Hellstrom , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Couple of comments inline. Paul Dean Willis wrote: > > > Adam Roach wrote: > >> Gunnar: >> >> I'm very confused. Why do you want to use MSRP for T.140 text? You >> don't *need* MSRP to have T.140 conversations. You just carry them >> like any other real-time streams -- isn't that the point of RFC 2793? >> > > Darn these cross-list discussions. You and Hisham seem to have missed > the first forty messages in this thread, and reacted with justifiable > surprise. > > Recap, for those who missed the first season of our serial drama: > > Gunnar does NOT "want" to use MSRP -- he proposed using T.140 exactly as > you discussed it above. He also wants real-time text in every phone and > messaging device produced, for 100% availability, a goal that I find > agreeable. > > However, I don't want to use T.140. Emulating reliability by requiring > multiple transmissions of every character without regard for real > network conditions is a horrible violation of the principles of RFC2914. > > So, I raised the question: Could we use a reliable and 2914-compliant > protocol like MSRP to meet the needs of real-time text? We are now > discussing this possibility, using MSRP as the baseline. Good summary. > Open questions: > > 1) Would the user experience be acceptable? > > 2) What is the bandwidth required, relative to T.140? Based on the back-of-envelope calculations in the thread, I think the conclusion was that it would take about 3 times the bandwidth to do with MSRP as it would with T.140 over RTP. (But of course, since TCP is a better citizen and is flow controlled, in times of congestion it might not hurt the network so much. But since it is sending 3 times the data, it will get congested more often, and the user experience will be bad in more cases.) > 3) How much change would this imply for MSRP? > > 4) How will this affect the widepsread availability of real-time text? > Cullen has proposed that if this is simple as a check-box in the GUI of > every MSRP client, then EVERYBODY has eal-time text capability. That effect could be achieved even with separate protocols. It is a matter of working out all the interop cases and specifying how it should be done. > 5) What are the pros and cons of the various approaches with respect to > firewalls and NATs? Clearly TCP has some advantages, and MSRP has > relays, but TURN and STUN give us some existing infrastructure for T.140. > > 6) is there a sufficient perception of value in the community to justify > adding this sort of function to MSRP, or would yet another protocol be > required? > > -- > Dean > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 29 15:00:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08778 for ; Tue, 29 Jun 2004 15:00:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfNqI-0001Z9-NL for simple-archive@ietf.org; Tue, 29 Jun 2004 15:00:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfNpR-0001Dh-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 14:59:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfNou-0000rJ-00; Tue, 29 Jun 2004 14:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfNit-0006Pc-ID; Tue, 29 Jun 2004 14:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfNbu-0005iq-77 for simple@megatron.ietf.org; Tue, 29 Jun 2004 14:45: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 OAA07967 for ; Tue, 29 Jun 2004 14:45:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfNbt-0003rj-4a for simple@ietf.org; Tue, 29 Jun 2004 14:45:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfNaj-0003Sz-00 for simple@ietf.org; Tue, 29 Jun 2004 14:44:26 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfNZe-0002la-00 for simple@ietf.org; Tue, 29 Jun 2004 14:43:18 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5TIemLp012445; Tue, 29 Jun 2004 13:40:48 -0500 Message-ID: <40E1B7B0.1060107@dynamicsoft.com> Date: Tue, 29 Jun 2004 13:40:48 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP: updates and re-invites References: <40E084FA.4030007@dynamicsoft.com> <40E097D0.6020401@cisco.com> <40E09AF7.8020500@dynamicsoft.com> <40E0A0E1.4060603@cisco.com> In-Reply-To: <40E0A0E1.4060603@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> In the shared connection model, connections are as-needed. By >> implication, we do not signal connections, we signal sessions. If we >> signal a session, and the endpoints already have a connection that >> will serve, they use it. >> >> So, if we don't signal the connections in the first place, why would >> we signal a new connection? > > > Unless I missed a change somewhere, connections *at the endpoints* are > not entirely as-needed. In particular, if a connection has gone away but > is still needed it cannot just be made again. Oops, yes, you are correct. > > But I agree that the need to do that can be defined away, by saying that > loss of the connection implies loss of the session, so that a new > session must be requested. > > I think this is what you mean, and if so that is fine. I just want to be > sure. Yes, that is what I mean. > > Paul > >> Paul Kyzivat wrote: >> >>> Ben, >>> >>> I think what you describe here is what we discussed at some point, >>> that should work. But the general wording below leaves me a bit >>> uncertain of that. Am I right that point below is that if the path is >>> unchanged then the old connections are reused, while when the path is >>> changed (by either end) then the offerer establishes a new connection? >>> >>> Paul >>> >>> Ben Campbell wrote: >>> >>>> We have had a lot of discussion on how to handle updated offers in >>>> SIP updates and re-invites. We had made some proposals back when we >>>> negotiated connection direction that are not really relevant any more. >>>> >>>> The design team spent some time discussing this, and came up with a >>>> proposal: >>>> >>>> Reconnection no longer an issue with connection sharing. TCP >>>> connection establishment is done on-demand. Therefore we do not need >>>> a way to signal a desire to establish a new TCP session. >>>> >>>> The offerer of a new sdp exchange assumes the role of offerer for >>>> all purposes, regardless of whether it was the origininal offerer. >>>> >>>> An offerer or answer is effectively unchanged if the path does not >>>> change from the previous version. If either side changes the path, >>>> then we effectively have a new session. >>>> >>>> If offerer does not change anything, answerers can still make >>>> changes. Answerer must always answer with a currently valid path. >>>> These could be the same as before the update, or different. >>>> >>>> Local policy may choose to re-invite to fix session problems without >>>> user interaction, or give user a choice. (examples: you get an error >>>> report to the initial send, a mobile device looses connectivity >>>> through tunnel, etc.) >>>> >>>> I invite everyone who cares to think this through, and make sure we >>>> are not breaking something important. >>>> >>>> Thanks! >>>> >>>> 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-bounces@ietf.org Tue Jun 29 15:10:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09791 for ; Tue, 29 Jun 2004 15:10:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfO01-000566-RH for simple-archive@ietf.org; Tue, 29 Jun 2004 15:10:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfNz4-0004kH-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 15:09:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfNyd-0004OF-00; Tue, 29 Jun 2004 15:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfNvi-0005XQ-J3; Tue, 29 Jun 2004 15:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfNpF-0007DI-L8 for simple@megatron.ietf.org; Tue, 29 Jun 2004 14:59: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 OAA08689 for ; Tue, 29 Jun 2004 14:59:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfNpE-0001Bz-HP for simple@ietf.org; Tue, 29 Jun 2004 14:59:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfNoF-0000pq-00 for simple@ietf.org; Tue, 29 Jun 2004 14:58:23 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfNnB-0000AH-00 for simple@ietf.org; Tue, 29 Jun 2004 14:57:17 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5TIukLp012495; Tue, 29 Jun 2004 13:56:46 -0500 Message-ID: <40E1BB6E.9050006@dynamicsoft.com> Date: Tue, 29 Jun 2004 13:56:46 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Simple] Using MSRP for real time text conversation References: <40E08FB8.2000505@dynamicsoft.com> <40E18E80.2060105@softarmor.com> In-Reply-To: <40E18E80.2060105@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: toip@snowshore.com, Adam Roach , Gunnar Hellstrom , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Re-adding my comments to this branch of the thread: Dean Willis wrote: > > > Adam Roach wrote: > >> Gunnar: >> >> I'm very confused. Why do you want to use MSRP for T.140 text? You >> don't *need* MSRP to have T.140 conversations. You just carry them >> like any other real-time streams -- isn't that the point of RFC 2793? >> > > Darn these cross-list discussions. You and Hisham seem to have missed > the first forty messages in this thread, and reacted with justifiable > surprise. > > Recap, for those who missed the first season of our serial drama: > > Gunnar does NOT "want" to use MSRP -- he proposed using T.140 exactly as > you discussed it above. He also wants real-time text in every phone and > messaging device produced, for 100% availability, a goal that I find > agreeable. > > However, I don't want to use T.140. Emulating reliability by requiring > multiple transmissions of every character without regard for real > network conditions is a horrible violation of the principles of RFC2914. > > So, I raised the question: Could we use a reliable and 2914-compliant > protocol like MSRP to meet the needs of real-time text? We are now > discussing this possibility, using MSRP as the baseline. > > Open questions: > > 1) Would the user experience be acceptable? > > 2) What is the bandwidth required, relative to T.140? If you send one char per message, absurdly huge. If you use some of the streaming features of MSRP, this might could be somewhat mitigated. But this would be an extremely constrained and mutant usage of MSRP as it is currently described. > > 3) How much change would this imply for MSRP? > I am assuming the 1 char per message approach is not even on the table. If you use a stream approach, you will need loads of new rules about how to do this, and how to signal you want to do it. > 4) How will this affect the widepsread availability of real-time text? > Cullen has proposed that if this is simple as a check-box in the GUI of > every MSRP client, then EVERYBODY has eal-time text capability. > I have no opinion on this. The jury is still out on the wide-spread acceptance of MSRP. > 5) What are the pros and cons of the various approaches with respect to > firewalls and NATs? Clearly TCP has some advantages, and MSRP has > relays, but TURN and STUN give us some existing infrastructure for T.140. > > 6) is there a sufficient perception of value in the community to justify > adding this sort of function to MSRP, or would yet another protocol be > required? Well, adding this to the MSRP base spec would be long and painful. I am in principle opposed to adding any significant new requirements to MSRP, as it would put at serious risk of never completing it. I also don't think that real-time text is in scope, or in charter, for SIMPLE. Now, if we, or someone else, decide(s) that it makes sense to extend MSRP to allow this, I am not strongly opposed, as long as it does not disrupt work on the base spec. (I am not by that statement indicating that I do thing it makes sense.) > > -- > Dean > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 29 17:57:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28113 for ; Tue, 29 Jun 2004 17:57:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQbr-0001sy-SF for simple-archive@ietf.org; Tue, 29 Jun 2004 17:57:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQQQ-0007CK-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 17:46:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfQDN-0004KZ-01; Tue, 29 Jun 2004 17:32:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfQAe-0006xH-56; Tue, 29 Jun 2004 17:29:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPyX-00011f-B3; Tue, 29 Jun 2004 17:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPTf-0005ww-3N for simple@megatron.ietf.org; Tue, 29 Jun 2004 16:45: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 QAA18422 for ; Tue, 29 Jun 2004 16:45:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfPTd-0002nZ-Py for simple@ietf.org; Tue, 29 Jun 2004 16:45:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfPGc-0007hl-00 for simple@ietf.org; Tue, 29 Jun 2004 16:31:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfP6w-0005MB-00 for simple@ietf.org; Tue, 29 Jun 2004 16:21:46 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfOxa-0003EI-3s for simple@ietf.org; Tue, 29 Jun 2004 16:12:06 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Tue, 29 Jun 2004 13:11:36 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 13:10:54 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 13:10:55 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 13:10:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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 Boundary header Date: Tue, 29 Jun 2004 13:10:54 -0700 Message-ID: Thread-Topic: [Simple] MSRP Boundary header thread-index: AcRdZwXRfeowKXR0Q+6uGTJuLmvySQArd5cA From: "Vijay Hampapur Hampapur Parthasarathy" To: "Ben Campbell" , "Aditya Bhasin" X-OriginalArrivalTime: 29 Jun 2004 20:10:41.0207 (UTC) FILETIME=[26D58C70:01C45E15] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Why cannot this be handled with a content length header that specifies the length of this chunk. And another header, say an ENDOFMESSAGE header bool, that specifies if the message is completely done or more pieces are present. This way the logic to parse would not need to look thro the entire message before sending (in order to ensure the boundary characters arent present) and to parse when reading to see where the current chunk (/message) ends Vijay -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Monday, June 28, 2004 3:47 PM To: Aditya Bhasin Cc: simple@ietf.org Subject: Re: [Simple] MSRP Boundary header The ability to handle large content has been a generally accepted requirement. The entire chunking mechanism is there due to this requirement. I do not understand what you mean by "being close to the application".=20 There a a number of ways an application could talk to the MSRP layer.=20 For an absurdly trivial example, you could simply pipe output from an app, and have MSRP recognize the end-of-file. Aditya Bhasin wrote: > What applications are being targeted for this to be an issue? >=20 > The size of the content will have to be extremely large and the=20 > application pretty close to a streaming application to be able to=20 > insert an ending boundary delimiter. >=20 > Sorry late to the discussions and only trying to understand what is=20 > driving this requirement. >=20 > thx > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, June 28, 2004 3:30 PM > To: Aditya Bhasin > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header >=20 > If you use message-length for framing purposes, then once you have=20 > sent the message-length value, you have to send that many bytes. If=20 > you don't, the peer cannot tell when the current message ends and the=20 > next one starts. Once the peer loses track of framing in this way,=20 > framing is lost for the entire connection. >=20 > We could probably fix this with some sort of sync protocol, but that=20 > would be more complex than just going to a delimiter approach to=20 > framing, which is exactly what the boundary is. >=20 >=20 >=20 > Aditya Bhasin wrote: >=20 >=20 >>Ben, >> >>Could you explain this a little more. >> >>Thx >> >>aditya >> >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>Behalf >=20 > Of >=20 >>Ben Campbell >>Sent: Monday, June 28, 2004 2:04 PM >>To: Murty Dasari >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP Boundary header >> >>The reason is, we added a requirement to be able abort a message=20 >>without destroying framing for the TCP connection. The boundary=20 >>approach has that property, content-length does not. >> >>Murty Dasari wrote: >> >> >> >>>Hello, >>> >>> >>> >>>I've a question about MSRP (based on >>>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >>> >>> >>> >>>What is the need for a "Closing" field? >>> >>> >>> >>>Can't we use "Content-Length" similar to HTTP for determining the=20 >>>message body length? If this is there for "Continuation-Flag" then=20 >>>probably we can have another header that indicates continuation status. >>>Though it might not be lot of work to determine the "closing" tag, it >>>might be easy for the relays and clients to retrieve the message body >>>based on content-length header; further, we don't have to add=20 >>>restrictions on presence of "boundary" in the message body in this case. >>> >>> >>> >>>This question might have brought-up/answered earlier, but I couldn't=20 >>>find out from the archives. Appreciate any comments. >>> >>> >>> >>>Thanks for your time. >>> >>>- Murty >>> >>> >>> >>> >>>--------------------------------------------------------------------- >>>--- >>> >>>_______________________________________________ >>>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-bounces@ietf.org Tue Jun 29 17:57:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28164 for ; Tue, 29 Jun 2004 17:57:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQc0-0001uu-Ta for simple-archive@ietf.org; Tue, 29 Jun 2004 17:57:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQQc-0007EQ-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 17:46:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfQDQ-0004KZ-00; Tue, 29 Jun 2004 17:32:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfQ7q-0006ht-EG; Tue, 29 Jun 2004 17:26:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPy5-0000ah-3L; Tue, 29 Jun 2004 17:16:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPON-0003OA-Oq for simple@megatron.ietf.org; Tue, 29 Jun 2004 16:39: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 QAA17621 for ; Tue, 29 Jun 2004 16:39:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfPOM-0001Yq-Bv for simple@ietf.org; Tue, 29 Jun 2004 16:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfPC4-0006co-00 for simple@ietf.org; Tue, 29 Jun 2004 16:27:06 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfP4Y-0004dY-00 for simple@ietf.org; Tue, 29 Jun 2004 16:19:18 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5TKImLp012935; Tue, 29 Jun 2004 15:18:48 -0500 Message-ID: <40E1CEA8.5050606@dynamicsoft.com> Date: Tue, 29 Jun 2004 15:18:48 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Hampapur Hampapur Parthasarathy Subject: Re: [Simple] MSRP Boundary header References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit That works if you abort message content between chunks. We are talking about either aborting or splitting a chunk in mid-stream. And the 06 draft already has something similar to your idea of an ENDOFMESSAGE flag in the continuation flag. The problem if, if you put a content-length at the front of a message, you obviously have to know how long that message is in advance. If I need to interrupt a chunk at some arbitrary point in its transmission, I have violated that knowledge. Vijay Hampapur Hampapur Parthasarathy wrote: > Why cannot this be handled with a content length header that specifies > the length of this chunk. And another header, say an ENDOFMESSAGE header > bool, that specifies if the message is completely done or more pieces > are present. This way the logic to parse would not need to look thro the > entire message before sending (in order to ensure the boundary > characters arent present) and to parse when reading to see where the > current chunk (/message) ends > > Vijay > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Monday, June 28, 2004 3:47 PM > To: Aditya Bhasin > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > The ability to handle large content has been a generally accepted > requirement. The entire chunking mechanism is there due to this > requirement. > > I do not understand what you mean by "being close to the application". > There a a number of ways an application could talk to the MSRP layer. > For an absurdly trivial example, you could simply pipe output from an > app, and have MSRP recognize the end-of-file. > > Aditya Bhasin wrote: > > >>What applications are being targeted for this to be an issue? >> >>The size of the content will have to be extremely large and the >>application pretty close to a streaming application to be able to >>insert an ending boundary delimiter. >> >>Sorry late to the discussions and only trying to understand what is >>driving this requirement. >> >>thx >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, June 28, 2004 3:30 PM >>To: Aditya Bhasin >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP Boundary header >> >>If you use message-length for framing purposes, then once you have >>sent the message-length value, you have to send that many bytes. If >>you don't, the peer cannot tell when the current message ends and the >>next one starts. Once the peer loses track of framing in this way, >>framing is lost for the entire connection. >> >>We could probably fix this with some sort of sync protocol, but that >>would be more complex than just going to a delimiter approach to >>framing, which is exactly what the boundary is. >> >> >> >>Aditya Bhasin wrote: >> >> >> >>>Ben, >>> >>>Could you explain this a little more. >>> >>>Thx >>> >>>aditya >>> >>>-----Original Message----- >>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>Behalf >> >>Of >> >> >>>Ben Campbell >>>Sent: Monday, June 28, 2004 2:04 PM >>>To: Murty Dasari >>>Cc: simple@ietf.org >>>Subject: Re: [Simple] MSRP Boundary header >>> >>>The reason is, we added a requirement to be able abort a message >>>without destroying framing for the TCP connection. The boundary >>>approach has that property, content-length does not. >>> >>>Murty Dasari wrote: >>> >>> >>> >>> >>>>Hello, >>>> >>>> >>>> >>>>I've a question about MSRP (based on >>>>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >>>> >>>> >>>> >>>>What is the need for a "Closing" field? >>>> >>>> >>>> >>>>Can't we use "Content-Length" similar to HTTP for determining the >>>>message body length? If this is there for "Continuation-Flag" then >>>>probably we can have another header that indicates continuation > > status. > >>>>Though it might not be lot of work to determine the "closing" tag, it > > >>>>might be easy for the relays and clients to retrieve the message body > > >>>>based on content-length header; further, we don't have to add >>>>restrictions on presence of "boundary" in the message body in this > > case. > >>>> >>>> >>>>This question might have brought-up/answered earlier, but I couldn't >>>>find out from the archives. Appreciate any comments. >>>> >>>> >>>> >>>>Thanks for your time. >>>> >>>>- Murty >>>> >>>> >>>> >>>> >>>>--------------------------------------------------------------------- >>>>--- >>>> >>>>_______________________________________________ >>>>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-bounces@ietf.org Tue Jun 29 17:58:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28209 for ; Tue, 29 Jun 2004 17:58:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQc6-0001w1-MJ for simple-archive@ietf.org; Tue, 29 Jun 2004 17:58:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQQj-0007Fi-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 17:46:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfQDT-0004KZ-00; Tue, 29 Jun 2004 17:32:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfQ6k-0006h2-RC; Tue, 29 Jun 2004 17:25:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPxw-0000MR-8X; Tue, 29 Jun 2004 17:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPM2-0002M8-NY for simple@megatron.ietf.org; Tue, 29 Jun 2004 16:37: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 QAA17226 for ; Tue, 29 Jun 2004 16:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfPM1-00017l-Bv for simple@ietf.org; Tue, 29 Jun 2004 16:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfP9e-0006Bk-00 for simple@ietf.org; Tue, 29 Jun 2004 16:24:35 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfP2A-0004D9-00 for simple@ietf.org; Tue, 29 Jun 2004 16:16:50 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5TKGbbo002534; Tue, 29 Jun 2004 16:16:37 -0400 (EDT) Message-ID: <40E1CE12.1030002@dynamicsoft.com> Date: Tue, 29 Jun 2004 16:16:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 8: Etag Scope References: <2038BCC78B1AD641891A0D1AE133DBB701797CCF@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CCF@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: drage@lucent.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >> -----Original Message----- From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf Of ext Jonathan Rosenberg >> Sent: 28.June.2004 14:30 To: Drage, Keith (Keith) Cc: Simple WG >> Subject: Re: [Simple] XCAP Issue 8: Etag Scope >> >> >> >> >> Drage, Keith (Keith) wrote: >> >> >>> It certainly would be useful to see use cases if people >> >> think we need >> >>> more complicated solutions. >> >> I'd also like to understand the use cases for this. Hisham, can you >> provide some more? > > > There is a requirement where key participants, for example, get the > privilege to modify the Dial-out list, the security parameters in a > conference, or add a media stream to the conference. Sure. The question, however, is whether, in these cases, its necessary to condition these operations on the current values? So, for the cases you mention: 1. modify dial-out list: I would imagine in most cases someone wants to add or remove a user from these lists. Removal doesn't require conditioning the DELETE. Adding doesnt require it either; if you want to make sure that the user isnt already there, you can do If-Not-Match: *. 2. modify security parameters: Here, I would imagine that the most common case is merely to *set* them, without regards to verifying that someone else hasn't tried to set them since you last checked. Would it make a difference if they had? Why not just PUT the whole ? 3. adding a media stream: I'm not exactly sure how this works, so I can't say if it can be done without a conditional operation. I'll also note that if you want to condition it, you still can; its just that if someone else has changed one of these other things, you may need to refetch the piece you care about. In my mind, the proposed text I sent out was *really* complicated, and was meant to make it clear that there is, IMHO, quite a lot of cost to this complex scope definitions. -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-bounces@ietf.org Tue Jun 29 17:58:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28306 for ; Tue, 29 Jun 2004 17:58:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQcQ-0001yu-TR for simple-archive@ietf.org; Tue, 29 Jun 2004 17:58:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQRA-0007K5-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 17:46:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfQDa-0004KZ-00; Tue, 29 Jun 2004 17:32:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfQ0N-0006RA-PL; Tue, 29 Jun 2004 17:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPvD-0007Pi-N6; Tue, 29 Jun 2004 17:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfP2C-0002xS-2L for simple@megatron.ietf.org; Tue, 29 Jun 2004 16:16: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 QAA15141 for ; Tue, 29 Jun 2004 16:16:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfP2A-0004IK-Hd for simple@ietf.org; Tue, 29 Jun 2004 16:16:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfOvC-0002WI-00 for simple@ietf.org; Tue, 29 Jun 2004 16:09:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfOqg-000197-00 for simple@ietf.org; Tue, 29 Jun 2004 16:04:58 -0400 Received: from av3-1-sn3.vrr.skanova.net ([81.228.9.109]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfOkp-0002VJ-Bm for simple@ietf.org; Tue, 29 Jun 2004 15:58:55 -0400 Received: by av3-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 669DF37E70; Tue, 29 Jun 2004 21:58:23 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 57D1E37E42; Tue, 29 Jun 2004 21:58:23 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 1B27538011; Tue, 29 Jun 2004 21:58:23 +0200 (CEST) From: "Gunnar Hellstrom" To: "Dean Willis" , "Ben Campbell" Subject: RE: [Simple] Using MSRP for real time text conversation Date: Tue, 29 Jun 2004 21:58:19 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40E1BB6E.9050006@dynamicsoft.com> Content-Transfer-Encoding: 7bit Cc: STF267 , Adam Roach , toip@snowshore.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks for good summaries and questions. Comments inline, >Re-adding my comments to this branch of the thread: > >Dean Willis wrote: > >> >> >> Adam Roach wrote: >> >>> Gunnar: >>> >>> I'm very confused. Why do you want to use MSRP for T.140 text? You >>> don't *need* MSRP to have T.140 conversations. You just carry them >>> like any other real-time streams -- isn't that the point of RFC 2793? >>> >> >> Darn these cross-list discussions. You and Hisham seem to have missed >> the first forty messages in this thread, and reacted with justifiable >> surprise. >> >> Recap, for those who missed the first season of our serial drama: >> >> Gunnar does NOT "want" to use MSRP -- he proposed using T.140 exactly as >> you discussed it above. He also wants real-time text in every phone and >> messaging device produced, for 100% availability, a goal that I find >> agreeable. >> >> However, I don't want to use T.140. Emulating reliability by requiring >> multiple transmissions of every character without regard for real >> network conditions is a horrible violation of the principles of RFC2914. It is not T.140 you are suspicious to, it is to use the RTP packetisation text/t140 as specified in rfc2793 ( and -bis ) that you have doubts about. The repetitions are sent together with new characters, and therefore do not cause any remarkable increase in load. The unusual characteristics of this rtp packetization makes it not as horrible as you seem to think. It is not a true character-by-character transmission. All characters typed during a buffering interval are transmitted together. The default buffering time is 300 ms. If no data is available for transmission, no packet is sent. User spend often more time thinking and reading than they spend typing. So, studying max values does not give you a good view of the real ( low ) load. The additional words about actions in case of congestion should be effective. RTCP info can be the base for increasing buffering time. >> >> So, I raised the question: Could we use a reliable and 2914-compliant >> protocol like MSRP to meet the needs of real-time text? We are now >> discussing this possibility, using MSRP as the baseline. >> >> Open questions: >> >> 1) Would the user experience be acceptable? With 300 ms between transmissions if there is data, I would expect MSRP to behave just as well as RTP text/t140, assuming that it gets through NAT and firewalls. We saw that the bandwidth seems to be 3 times higher for MSRP. If we compensate by increasing buffering time we reach 1 second buffering time, and that will be regarded too slow and chunky. 500 ms is the limit. >> >> 2) What is the bandwidth required, relative to T.140? > >If you send one char per message, absurdly huge. If you use some of the >streaming features of MSRP, this might could be somewhat mitigated. But >this would be an extremely constrained and mutant usage of MSRP as it is >currently described. With maximum allowable 500 ms for MSRP it will be 4 kbit/s. With 300 ms buffering it will be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a mobile situation. Otherwise it is probably OK. We are dealing with calls where it will be in many cases favourable to use video and audio as well. > >> >> 3) How much change would this imply for MSRP? >> > >I am assuming the 1 char per message approach is not even on the table. >If you use a stream approach, you will need loads of new rules about how >to do this, and how to signal you want to do it. Look at 500 ms buffering instead. Would you dare to recommend it then? > >> 4) How will this affect the widepsread availability of real-time text? >> Cullen has proposed that if this is simple as a check-box in the GUI of >> every MSRP client, then EVERYBODY has eal-time text capability. >> > >I have no opinion on this. The jury is still out on the wide-spread >acceptance of MSRP. I definitely hope that simple and MSRP gets widespread. The current fragmentation in the I M world is a severely hampering factor for its message-wise use. Impossible to procure for official use, impossible to use for public services. I wish you all luck with a standardised protocol to replace the current situation! But for its influence on the real time variant, I also want to listen to the word from the jury... > >> 5) What are the pros and cons of the various approaches with respect to >> firewalls and NATs? Clearly TCP has some advantages, and MSRP has >> relays, but TURN and STUN give us some existing infrastructure for T.140. There are also true SIP aware NAT-routers and firewalls that handle SIP and RTP well. I do not know how well they handle MSRP. >> >> 6) is there a sufficient perception of value in the community to justify >> adding this sort of function to MSRP, or would yet another protocol be >> required? > >Well, adding this to the MSRP base spec would be long and painful. I am >in principle opposed to adding any significant new requirements to MSRP, >as it would put at serious risk of never completing it. Three small things need to be done: a. Optional real time transmission in 500 ms buffers. b. MIME declaration of the transmission in a new text/t140p format that is just the plain UTF-8 coded T.140 transmission. c. A request on the receiver to add received text for display in one window per transmitting party. > >I also don't think that real-time text is in scope, or in charter, for >SIMPLE. > >Now, if we, or someone else, decide(s) that it makes sense to extend >MSRP to allow this, I am not strongly opposed, as long as it does not >disrupt work on the base spec. (I am not by that statement indicating >that I do thing it makes sense.) > Same here, we have to judge the possible outcome of question 4 above, and balance it against the influence on already started activities to specify text/t140 as the way to do text conversation, emergency etc. Gunnar >> >> -- >> Dean >> >> _______________________________________________ >> 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-bounces@ietf.org Tue Jun 29 18:00:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28900 for ; Tue, 29 Jun 2004 18:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQeP-0002LZ-SK for simple-archive@ietf.org; Tue, 29 Jun 2004 18:00:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQUP-0007n7-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 17:50:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQDz-0004MT-00; Tue, 29 Jun 2004 17:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPzJ-0001wq-1w; Tue, 29 Jun 2004 17:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPgZ-0003Ej-Ej for simple@megatron.ietf.org; Tue, 29 Jun 2004 16:58: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 QAA19804 for ; Tue, 29 Jun 2004 16:58:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfPgY-0005N8-3w for simple@ietf.org; Tue, 29 Jun 2004 16:58:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfPOj-0001dJ-00 for simple@ietf.org; Tue, 29 Jun 2004 16:40:11 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BfPCR-0006be-00 for simple@ietf.org; Tue, 29 Jun 2004 16:27:27 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Tue, 29 Jun 2004 13:26:58 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 13:26:34 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 13:26:34 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 13:26:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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 Boundary header Date: Tue, 29 Jun 2004 13:26:40 -0700 Message-ID: Thread-Topic: [Simple] MSRP Boundary header thread-index: AcReFm6sMrzl7OHvTqSWKTOncNB4UQAAGPMg From: "Vijay Hampapur Hampapur Parthasarathy" To: "Ben Campbell" X-OriginalArrivalTime: 29 Jun 2004 20:26:36.0338 (UTC) FILETIME=[6022F920:01C45E17] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable But the Stack that is sending this stream out needs to packetise it at some point, at that point in time we do know the exact length of the amount we are sending in this one packet and that can be included as a header. And if you are talking about relays that need to rechunk messages for slow b/w links, then they already know how much of the message has been received and what size of chunk is acceptable on this segment in order to split it up. Maybe I don't fully understand the specific streamin application you have in mind where this kind of unknown length upfront would be required. Thanks Vijay -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: Tuesday, June 29, 2004 1:19 PM To: Vijay Kishen Hampapur Parthasarathy Cc: Aditya Bhasin; simple@ietf.org Subject: Re: [Simple] MSRP Boundary header That works if you abort message content between chunks. We are talking about either aborting or splitting a chunk in mid-stream. And the 06 draft already has something similar to your idea of an ENDOFMESSAGE flag in the continuation flag. The problem if, if you put a content-length at the front of a message, you obviously have to know how long that message is in advance. If I need to interrupt a chunk at some arbitrary point in its transmission, I have violated that knowledge. Vijay Hampapur Hampapur Parthasarathy wrote: > Why cannot this be handled with a content length header that specifies > the length of this chunk. And another header, say an ENDOFMESSAGE=20 > header bool, that specifies if the message is completely done or more=20 > pieces are present. This way the logic to parse would not need to look > thro the entire message before sending (in order to ensure the=20 > boundary characters arent present) and to parse when reading to see=20 > where the current chunk (/message) ends >=20 > Vijay >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf Of Ben Campbell > Sent: Monday, June 28, 2004 3:47 PM > To: Aditya Bhasin > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header >=20 > The ability to handle large content has been a generally accepted=20 > requirement. The entire chunking mechanism is there due to this=20 > requirement. >=20 > I do not understand what you mean by "being close to the application". > There a a number of ways an application could talk to the MSRP layer.=20 > For an absurdly trivial example, you could simply pipe output from an=20 > app, and have MSRP recognize the end-of-file. >=20 > Aditya Bhasin wrote: >=20 >=20 >>What applications are being targeted for this to be an issue? >> >>The size of the content will have to be extremely large and the=20 >>application pretty close to a streaming application to be able to=20 >>insert an ending boundary delimiter. >> >>Sorry late to the discussions and only trying to understand what is=20 >>driving this requirement. >> >>thx >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, June 28, 2004 3:30 PM >>To: Aditya Bhasin >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP Boundary header >> >>If you use message-length for framing purposes, then once you have=20 >>sent the message-length value, you have to send that many bytes. If=20 >>you don't, the peer cannot tell when the current message ends and the=20 >>next one starts. Once the peer loses track of framing in this way,=20 >>framing is lost for the entire connection. >> >>We could probably fix this with some sort of sync protocol, but that=20 >>would be more complex than just going to a delimiter approach to=20 >>framing, which is exactly what the boundary is. >> >> >> >>Aditya Bhasin wrote: >> >> >> >>>Ben, >>> >>>Could you explain this a little more. >>> >>>Thx >>> >>>aditya >>> >>>-----Original Message----- >>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 >>>Behalf >> >>Of >> >> >>>Ben Campbell >>>Sent: Monday, June 28, 2004 2:04 PM >>>To: Murty Dasari >>>Cc: simple@ietf.org >>>Subject: Re: [Simple] MSRP Boundary header >>> >>>The reason is, we added a requirement to be able abort a message=20 >>>without destroying framing for the TCP connection. The boundary=20 >>>approach has that property, content-length does not. >>> >>>Murty Dasari wrote: >>> >>> >>> >>> >>>>Hello, >>>> >>>> >>>> >>>>I've a question about MSRP (based on >>>>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >>>> >>>> >>>> >>>>What is the need for a "Closing" field? >>>> >>>> >>>> >>>>Can't we use "Content-Length" similar to HTTP for determining the=20 >>>>message body length? If this is there for "Continuation-Flag" then=20 >>>>probably we can have another header that indicates continuation >=20 > status. >=20 >>>>Though it might not be lot of work to determine the "closing" tag,=20 >>>>it >=20 >=20 >>>>might be easy for the relays and clients to retrieve the message=20 >>>>body >=20 >=20 >>>>based on content-length header; further, we don't have to add=20 >>>>restrictions on presence of "boundary" in the message body in this >=20 > case. >=20 >>>> >>>> >>>>This question might have brought-up/answered earlier, but I couldn't >>>>find out from the archives. Appreciate any comments. >>>> >>>> >>>> >>>>Thanks for your time. >>>> >>>>- Murty >>>> >>>> >>>> >>>> >>>>-------------------------------------------------------------------- >>>>- >>>>--- >>>> >>>>_______________________________________________ >>>>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 > _______________________________________________ > 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-bounces@ietf.org Tue Jun 29 18:02:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29283 for ; Tue, 29 Jun 2004 18:02:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQfx-0002e9-8w for simple-archive@ietf.org; Tue, 29 Jun 2004 18:02:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQWl-0000OK-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 17:52:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQG8-0004in-00; Tue, 29 Jun 2004 17:35:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQ00-0002jT-I8; Tue, 29 Jun 2004 17:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfPnK-0004zU-BW for simple@megatron.ietf.org; Tue, 29 Jun 2004 17:05: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 RAA20692 for ; Tue, 29 Jun 2004 17:05:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfPnJ-0006od-0t for simple@ietf.org; Tue, 29 Jun 2004 17:05:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfPVw-0003D7-00 for simple@ietf.org; Tue, 29 Jun 2004 16:47:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfPIT-00008s-00 for simple@ietf.org; Tue, 29 Jun 2004 16:33:42 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5TKX4Lp013034; Tue, 29 Jun 2004 15:33:05 -0500 Message-ID: <40E1D201.4020604@dynamicsoft.com> Date: Tue, 29 Jun 2004 15:33:05 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 9: Etags mostly useless for insert References: <2038BCC78B1AD641891A0D1AE133DBB701797CC4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CC4@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I also prefer option 1. hisham.khartabil@nokia.com wrote: > Option 1 gets my vote. If you want an if-match on a "scope", then you would need to replace the whole "scope". > > Thanks, > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Jonathan Rosenberg >>Sent: 24.June.2004 06:19 >>To: Simple WG >>Subject: [Simple] XCAP Issue 9: Etags mostly useless for insert >> >> >>While working through the text on etags, I ran into an interesting >>issue. Its not clear its a problem, but its something that >>needs to be >>documented if we decide its not. >> >>The issue is that, when you do a conditional PUT (that is, a >>PUT with an >>If-Match containing an etag), the conditioning is based on >>the etag for >>*that* resource. There is no way to say, "perform this PUT on >>resource >>X, but only if the etag for resource Y has not changed". Why >>is this an >>issue? Well, let me give a concrete example. >> >>Lets say I have a basic buddy list that looks like this: >> >> >>>xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand" >>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> >> >subscribeable="true"> >> >> Bill Doe >> >> > subscribeable="true"> >> >> Joe Smith >> >> >> Nancy Gross >> >> >>http://www.example.org/xcap/resource-lists/users/a/foo >> >> >> >> >> >>and lets consider the simplest etag scope (this issue doesnt >>matter what >>we decide to do for etag scopes per issue 8), where every resource in >>the document has the same value for its etag. Its important to >>understand that etags are associated with a resource. Even if >>we decide >>that all resources will share the same value for their etags, >>they still >>each have their own etags. >> >>Lets say that the current etag for this document (and all resources >>within it) is 2. I decide to insert a new entry, and so I do this: >> >>PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ >> resource-lists/list[@name="friends"]/entry[@name="Mikko"] >>If-Match: 1 >> >> >> >> >> >>You would think that this insertion would be done if the document had >>not been modified (i.e., its etag was still 1), but that is NOT what >>this request will do. The conditioning here means that the >>PUT is only >>done if the etag for the resource in the request URI has an >>etag of 1. >>Of course, the resource in the request URI doesnt yet exist >>(thats why >>its an insert), so this request will be rejected with a 412. >> >>Basically, there is no way to do an insert, and say, "don't do this >>insertion if the document hasn't changed since etag 1". You can say, >>"don't do this insert if this resource exists", by using an >>If-Not-Match: *. So, you can at least guarantee that what you >>think is >>an insertion, really is an insertion. >> >>So, the question is, is this a problem? I don't think so. Or, more >>concretely, I couldn't think of a use case where this was a problem. >> >>Consider the following example. Once again, we have the >>document above, >>and client A has a copy of it locally, in memory, with etag >>1. Client 2 >>makes a change, and the change it makes is to delete the >>close-friends >>list. Client 1 then tries to do an insert into this list, and >>so it does: >> >>PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ >> resource-lists/list[@name="friends"]/ >> list[@name="close-friends"]/entry[@name="Paul"] >> >> >> >>Fortunately, this will request will fail with a 409, since >>the parent of >>entry[@name="Paul"] doesnt exist anymore. The client could >>then refetch >>the document and figure out why this error happened. >> >>So, no problem here. >> >>COnsider a different case. Client 1 has this list locally. Client 2 >>changes the name of "close-friends" to "really-close-friends". Same >>thing happens as the previous example. >> >>In yet another case, client 2 changes the subscribeable flag for >>close-friends from true to false. In this case, the insert done by >>client 1 will succeed. THe problem is that the client no longer has a >>correct copy of the document cached. If this is a problem, the client >>can refetch the document. >> >>I'll also note that, if you use the xcap package, this problem pretty >>much goes away. >> >>As far as I can tell, we have three choices about what to do >>about this >>"problem": >> >>1. document the situation so its clear what etags do and >>don't do for you >> >>2. instead of thinking about resources within a document as "not >>existing" when they aren't there, we can think about them as >>existing, >>but empty. If we stretch our imaginations a bit, we could think about >>assigning etags to empty resources. In that case, you basically never >>really do insertions; you only ever do modifications, and you might >>modify something from being empty to having actual value. In >>that case, >> you could usefully use etags to condition an "insertion" on >>whether or >>not the entire document has changed since you cached a copy. >>I consider >>this quite ugly. >> >>3. Define an HTTP extension which allows you to condition a request >>based on the etag of a different request on the server. >> >>I think we should do 1. I think the costs of doing more complicated >>locking and transaction mechanisms (which is what we are >>talking about) >>are too high to pay for this functionality we want right now. >>If these >>things prove really important, we can work them in through >>xcap extensions. >> >>Comments and input are welcome. >> >>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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 29 18:09:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00813 for ; Tue, 29 Jun 2004 18:09:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQnC-0004ek-MU for simple-archive@ietf.org; Tue, 29 Jun 2004 18:09:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQjB-0003U2-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:05:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQc2-0001fo-00; Tue, 29 Jun 2004 17:57:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQQr-0003L5-JA; Tue, 29 Jun 2004 17:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQJh-0000AC-QI for simple@megatron.ietf.org; Tue, 29 Jun 2004 17:39: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 RAA25528 for ; Tue, 29 Jun 2004 17:38:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQJg-0005Rx-BJ for simple@ietf.org; Tue, 29 Jun 2004 17:39:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQ16-0001co-00 for simple@ietf.org; Tue, 29 Jun 2004 17: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 1BfPeG-0004sw-00 for simple@ietf.org; Tue, 29 Jun 2004 16:56:12 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5TKtZLp013258; Tue, 29 Jun 2004 15:55:35 -0500 Message-ID: <40E1D748.5030804@dynamicsoft.com> Date: Tue, 29 Jun 2004 15:55:36 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Leion Subject: Re: [SIMPLE] Authorization of resource list back-end subscriptions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple mailinglist X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit There is one very fundemental point of the event list draft that seems to be missing from this discussion: The draft decscribes normative behavior on how one subscribes to a resource list, how the RLS constructs the aggregate state data, etc. It very explicitly does _not_ specify normative behavior on how the RLS aquires the event state for each list member. The use of back-end subscriptions is simply one way you could do this. We have pointed out some issues related to subscriber identity, but we have not stated requirements about it. There is nothing in the draft that _forbids_ the RLS from subscribing on its own behalf. Henrik Leion wrote: > I give up. > But I'm still convinced that SIP should have the option to have less > security (security can be provided by other means) for the benefit of > automatically authorize subscriptions from a dynamic group as a group > instead of per user. > Since the geopriv Common Policy only allows one uri element per rule, > presentities will have to create one rule per subscriber. > > In the Porsche example, Bob and the other presentities would need to create > 200 rules each, and add new as new members joined. By hand. > Changing the From-header in the resource-list subscriptions seemed like a > simple fix. One rule each. > > But if resource-lists will only be used for buddylists, I guess it's ok. > > /Henrik > > > PS. > About that car thief. He couldn't be avoided in the Porsche discussion group > even if all subscriptions were labelled pres.example.com and the > presentities authorized every single subscription by hand. The presentities > would know the true identity of all members, but they still wouldn't know > who took their cars. > > > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >>Of Paul Kyzivat >>Sent: den 22 juni 2004 17:28 >>To: Henrik Leion >>Cc: Simple mailinglist >>Subject: Re: [SIMPLE] Authorization of resource list back-end >>subscriptions >> >> >>Henrik, >> >>I think you are conflating unrelated concepts. The fact that I subscribe >>to the porsche-owners list doesn't make me a porsche-owner. >> >>(In fact I may well aspire to be a porsche-owner by first being a >>porsche-thief!) >> >>So it would be pretty dumb of you to grant me permission to subscribe to >>your presence solely because I have subscribed to the porsche-owners list. >> >>What *might* make sense would be to find a way to share a single list >>for two uses - as a buddy list for subscribing to presence, and as a >>white list for *authorizing* subscription to presence. Then you might >>choose both to subscribe to porsche-owners, and to use the >>porsche-owners list as a white list for granting subscriptions to your >>presence. (There are of course technical issues with accomplishing that.) >> >> Paul >> >>Henrik Leion wrote: >> >>>Hmm, I feel we're talking and thinking about different things. >>>All I'm saying is that it could be useful to see in what context someone >>>wants my presence info, resource-lists can be used not only to make >>>subscribing easier - it could help a presentity group subscriptions and >>>automate authorization. >>>Resource-lists can be so much more than just a server-sided >> >>buddylist (where >> >>>end-to-end authorization is undoubtedly best), think discussion-groups, >>>conferences, games and future event packages. >>> >>>I'm not suggesting any changes in how subscribers are >> >>authenticated, only >> >>>that more information is given to the presentity to help him set up >>>authorization rules (to automate more, not less). >>>If the presentity would like to challenge a subscription >> >>request, he would >> >>>still identify the resource-list subscriber as usual. >>> >>>Consider this scenario: >>>Bob (sip:Bob@bobs-company.com) is a member of these resource-lists: >>> L1=Bobs-family@rls.example.com with 5 subscribers (Bob and >> >>his family) >> >>> L2=Porsche-Owners@rls.example.com with 200 subscribers >>> >>>Bob would like to publish much info to his family, but very >> >>limited info to >> >>>other Porsche-owners (say online status from his chat-client at >> >>home and his >> >>>cell phone's geoloc info when he's driving his Porsche). Bob accepts the >>>risks with sending geoloc info to strangers, because he thinks >> >>it's a nice >> >>>way of meeting new friends and would like automate the authorization for >>>members of that list. >>> >>>But when Bob gets a (back-end) subscription from >> >>pres.example.com, challenge >> >>>it and finds out it's Alice@another.domain.com, he still >> >>doesn't know if she >> >>>owns a Porsche, or if it's his cousin. >>>If Bob instead gets a subscription from >> >>porshe-owners@rls.example.com (again >> >>>initialized by Alice), he may be content with that, not caring about the >>>identity of that particular Porshe-owner, and set his policies to >>>automatically authorize this subscription. >>> >>>The ideas on writing resourcelist-subscribers in presentity >> >>watcher-info and >> >>>allowing presentity to write authorization-rules for >> >>resource-lists are a >> >>>bit far out, I'll admit, but if the resource-lists are made >> >>more visible, it >> >>>would be possible for those software developers inclined. >>> >>>Although I never meant to suggest it, the possibility of having >> >>the RLS to >> >>>authenticate itself, instead of forwarding the authentication >> >>request to the >> >>>subscriber, is interesting (not annoying). The key is that if >> >>the presentity >> >>>does not know the subscriber, an authentication would not be very >>>informative. But if the owner of the list instead says "I will >> >>personally >> >>>check that every subscriber is entitled to be on this list and kick out >>>those that misbehave", and the subscribers trust him, they will have the >>>possibility to automate authorization of strangers with more security. >>>Check out the game Mogi >> >>(http://www.thefeature.com/article?articleid=100501) >> >>>that could use Sip this way. >>> >>>/Henrik >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: den 21 juni 2004 16:35 >>>>To: Henrik Leion >>>>Cc: Simple mailinglist >>>>Subject: Re: [SIMPLE] Authorization of resource list back-end >>>>subscriptions >>>> >>>> >>>> >>>> >>>>Henrik Leion wrote: >>>> >>>> >>>>>Well, I just thought I'd toss in the idea. I believe that >>>> >>>>domains will be >>>> >>>> >>>>>small (office or home networks even) and that both inter-domain >>>>>subscriptions and resource-list subscriptions will be very >> >>common. I was >> >>>>>thinking in these lines: >>>>> >>>>>- If the ideas with filters, authorization rules and partial >>>> >>>>presence will >>>> >>>> >>>>>be implemented, how many users can there be on one >>>> >>>>presence-server? Parsing >>>> >>>> >>>>>xml-docs is quite more time-consuming than just forwarding requests. >>>> >>>>I too am worried about this. Something that prevents a PS from having to >>>>send a separate NOTIFY, with customized content, for every direct >>>>subscriber, including thost that arrive indirectly via a list, would be >>>>a good thing. But I'm not convinced you have found the right solution. >>>> >>>> >>>> >>>>>- How large parts of the resource-lists will actually come >>>> >>>>from the same >>> >>>>>presence-server and how much is back-end subscriptions? >>>>>- If subscriptions are to be authorized using watcher-info >>>> >>>>notification and >>>> >>>> >>>>>XCAP, isn't it a bit boring that it just says >>>> >>>>"pres.example.com" instead of >>>> >>>> >>>>>at least saying what resource-list your presence is publicated >>>> >>>>on? Better >>>> >>>> >>>>>yet is that the winfo-file states the subscribers to the >> >>resource-lists. >> >>>>Jonathan addressed this point. I'm with him on it. >>>> >>>> >>>> >>>>>>- what kind of credential could the RLS have and provide when >>>>>>subscribing that authenticates it as the resource-list? >>>>> >>>>>Well, actually I don't know. But what difference is there >> >>between an RLS >> >>>>>authenticating itself to a presentity using some >>>> >>>>"sip:pres.example.com" URI, >>>> >>>> >>>>>than should it use "sip:adam-friends@lists.example.com"? >>>>>In either case the presentity have probably never heard of example.com >>>>>before. >>>> >>>>If it were to authenticate as itself, then I agree its likely that >>>>nobody would grant it authorization. Authenticating as the list itself >>>>is indeed an improvement over that, but not a great one, because >>>>authorizing it doesn't give me real control over who receives my >>>>presence. More on that below. >>>> >>>> >>>> >>>>>>- in case of private lists (e.g. I am the only one who subscribes to >>>>>>*my* buddy list) having credentials for my buddy list is no >> >>easier than >> >>>>>>having credentials for me. >>>>> >>>>>Yes, I was thinking in the lines of public lists; intranet >>>> >>>>address-lists, >>>> >>>> >>>>>conferences, discussion groups etc. But I'm under the >>>> >>>>impression that the >>>> >>>> >>>>>RLS does not use the presentities credentials when creating a back-end >>>>>subscription but instead acts on its own, "RLSes acts as a subscriber" >>>>>[event-list draft]. >>>> >>>>Again, Jonathan spoke to this. Using the ultimate subscriber's >>>>credentials is pretty important. >>>> >>>>*If* a list were *known* to be available to only a single subscriber (or >>>>known list of subscribers I suppose), then authorizing based on >>>>credentials for the list itself would perhaps be acceptable. (Though >>>>annoying.) E.g. If I had a pending subscription from: >>>> >>>> sip:JohnSmith-buddylist@rls.example.com >>>> >>>>and sip:JohnSmith@example.com is indeed a buddy of mine, and I am >>>>familiar with the example.com rls server and that buddy lists aren't >>>>shared, then I might be inclined to grant the subscription. >>>> >>>> >>>> >>>>>>- if the RLS server has lists L1 and L2 that both have a reference to >>>>>>presentity P, then it still can't use a single subscription to P and >>>>>>provide results to subscribers of both L1 and L2. >>>>> >>>>>Yes it could. >>>>>P.winfo would contain L1 and L2 along with all other watchers that are >>>>>interested in the presence of P. If P wants to check who >>>> >>>>actually subscribes >>>> >>>> >>>>>to L1 and L2, he would consult L1.winfo and L2.winfo. >>>> >>>>This is very different than the expected authorization model for >>>>presence subscriptions. Normally, P will not care about authorized >>>>watchers in P.winfo. Instead, all it will care about are those that are >>>>'pending'. They are the watchers that want access to P's presence but >>>>that have neither been granted nor denied it. User P then either grants >>>>or denies them access, and never gives them another thought. >>> >>> >>>Ah, yes. That what the draft says. Thanks >>> >>> >>> >>>>In the case of L1 and L2, P has to decide whether to grant access the >>>>first time the server subscribes on behalf of each. User P can check who >>>>is currently watching L1 or L2 at that time, but that will say nothing >>>>about who may watch them at some other time. >>>> >>>> >>>> >>>>>Another idea is to add a namespace to winfo for resourcelists, >>>> >>>>now P can see >>>> >>>> >>>>>anybody subscribing to him directly, instead of just knowing >>>> >>>>that an RLS is >>>> >>>> >>>>>subscribing. >>>> >>>>This doesn't solve the problem. As a notifier, I don't want to have to >>>>recognize that a particular watcher is a list and then monitor the >>>>subscribers of that list to decide moment-by-moment what I am >>>>comfortable publishing to that set of watchers. And even if I was >>>>willing to, there would be race conditions so that what I publish could >>>>go to someone I didn't expect >>>> >>>>For such a system to work at all, it would need to be based on who is >>>>*authorized* to watch the list, not who is currently watching it. And >>>>even then, it would be a bad system. The notifier would have to tailor >>>>the content published to the intersection of what it is willing to make >>>>available to any of the potential subscribers to the list. That isn't >>>>going to be very appealing to subscribers that would otherwise be able >>>>to see more. >>>> >>>> >>>> >>>>>>Well, maybe it *could* but that sounds really cumbersome, >> >>expensive, and >> >>>>>>not especially reliable. Can I ever safely decide what to >> >>disclose based >> >>>>>>on who I think is currently subscribing to that list, rather than who >>>>>>potentially *could* subscribe to it? >>>>> >>>>>But that's the whole idea behind presence authorization using >>>> >>>>winfo-lists, >>>> >>>> >>>>>isn't it? >>>> >>>>No. See above. >>>> >>>> >>>>>That you can trust the presence server that it only sends your >>>> >>>>>presence information to those watchers that are marked "active" in your >>>>>winfo-file. When new subscriptions come, the presence server >> >>will either >> >>>>>allow or disallow it judging from authorization rules, or >>>> >>>>otherwise set the >>>> >>>> >>>>>subscription-state to "pending" and let the presentity decide. >>>>>If you don't trust that the server will act this way in the >> >>future, send >> >>>>>less information. >>>> >>>>This is way to dynamic for making policy decisions. >>>> >>>> >>>> >>>>>Those present on a resource-list should be allowed to create >>>> >>>>resource-list >>>> >>>> >>>>>authorization rules appliable to their own presence. >>>>>L1 has two subscribers S1a and S1b. P may be authorized to >>>> >>>>create a rule in >>>> >>>> >>>>>L1.auth that always transforms his presence to appear offline >>>> >>>>to S1b, whilst >>>> >>>> >>>>>S1a will get P's true presence. >>>>>The authorization rules of a resource list should belong to the >>>> >>>>people on >>>> >>>> >>>>>it, at least in public applications, such as conference lists. But in a >>>>>black-list or buddylist application the idea is probably quite stupid. >>>> >>>>Well, that would solve some of the problems. But it presents serious >>>>issues of trust. Why should I believe that I can trust the RLS managing >>>>L1 to administer my policies? >>>> >>>>And mechanistically, I don't think I would want to deal with that kind >>>>of authorization manually. >>>> >>>>It sounds to me like that is a potential optimization that could be >>>>carried out among a set of mutually cooperating servers that have >>>>suitable mutual trust arrangements. In that case the user should not >>>>have to do anything special - the appropriate authorization rules would >>>>be shared among the servers. >>>> >>>> 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 >> > > > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 29 18:09:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00934 for ; Tue, 29 Jun 2004 18:09:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQnb-0004hn-84 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:09:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQjr-0003ri-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:06:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQdi-00027x-00; Tue, 29 Jun 2004 17:59:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQTI-0003tI-JG; Tue, 29 Jun 2004 17:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQLb-0000n0-VW for simple@megatron.ietf.org; Tue, 29 Jun 2004 17:41: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 RAA26001 for ; Tue, 29 Jun 2004 17:40:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQLa-0005oc-Eq for simple@ietf.org; Tue, 29 Jun 2004 17:40:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQ4w-0002IA-00 for simple@ietf.org; Tue, 29 Jun 2004 17:23:48 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfPi0-0005Xi-00 for simple@ietf.org; Tue, 29 Jun 2004 17:00:04 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5TKxnbo002567; Tue, 29 Jun 2004 16:59:51 -0400 (EDT) Message-ID: <40E1D831.9090602@dynamicsoft.com> Date: Tue, 29 Jun 2004 16:59:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple ele ments References: <1086870176.2885.93.camel@xitami.research.nokia.com> In-Reply-To: <1086870176.2885.93.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit responses inline. But first, I will say that there was really strong consensus during the interim to omit this feature in the first version of the specification. As such, unless others speak out in favor of adding it, I think that we can declare that the consensus in the interim Jari Urpalainen wrote: >>(2) the server keeps a copy of the document before the operation. It=20 >>then tries the PUT. Once done, it pretends that the client did a GET=20 >>back to the same URI, and it sees what comes back. If its the same as=20 >>was in the body of the PUT, the operation was idempotent, and the PUT i= >>accepted. If not, the server goes back to the document before the=20 >>operation was done, and rejects the PUT request. This can be summarized= >>as "try it and see if it works". >>=20 > > > model (2) is almost what i have implemented for the following reason: > > first you have a document like > > > > > and then a client might try to e.g. add foo/bar[@id=3D"5"] with content > . First, as we don't find any node with the request, it is > an appending request and without any error-checking you may end up with > an end document like > > > > > > > Clearly this is an error in the client and IMO the server has to detect > this. The easy way that I chose to check this error-condition is that I > check that the last XPATH location step will return the correct node. So > my point is that not only the multi-inserts need this checking.=20 You are right that this problem can happen even in the single-insert cast. However, there, its much, much easier to check. You merely need to make sure that the attribute predicate in the r-uri applies to the element in the body of the request. That can be done before the insertion operation even takes place, thus avoiding the need for any kind of roll-back. > > Jonathan, I have still this question in another thread, where > idempotency is easily broken during replace (or modify) with single > nodes too. Different from the above issue? Can you please restate it? > Btw. could someone explain how DELETE can be idempotent > (rfc2616) ? Its a mystery to me. The second DELETE will generate a 404, since the previous one did a good job of deleting the resource. >>HTTP PUT operations. So long as you don't need the etag from the=20 >>previous operation, this would work. Its bandwidth overhead is almost=20 >>the same as multiple insertions that we've been proposing, and the=20 >>latency is just about the same thing too. >>=20 > > > I'd rather say that pipelining could work in some cases, but it is NOT a > solution for doing atomic conditional multi-insertions/deletions which I > still would like to see in XCAP.=20 Well, again it comes back to what xcap is trying to do. It is not meant to be a general XML database protocol. I think its a feature of the design that it can be pushed towards that by adding features like multiple-inserts, but really its not our goal. Also, I'll note that if you want a sequence of insertions AND deletions to be done atomically, you can't do that with the multiple-inserts appraoch, since that only works with a single PUT (no DELETE). Thus, you would need proper transaction semantics that allow you to lock the document, make a bunch of changes, and cancel/rollback or commit when done, and that is, I think, well beyond what we want here. > > >>I suggested that I could include some guidelines on schema design to=20 >>avoid the need for mutliple insertions. There seemed to be support for=20 >>this position. The guidelines I will include are basically this: >>=20 >>(1) if you think you need multiple insertions because you think a commo= > > n=20 > >>operation will require making two separate changes to the document, try= > > =20 > >>"inverting" the schema so that this doesnt happen. For example, if you = > > have: > >>=20 >> >> >> >> >> >> >> >> >>=20 >>and adding requires it to go in and , try doing=20 >>the schema like this: >>=20 >> >> >> >> >> >> >> >> >> >> >>=20 >>(2) if you think you need multiple inserts because you want to add=20 >>multiple entries to a list in one operation, then design the schema to=20 >>facilitate pipelined PUT. Specifically, make sure that each entry in th= > > e=20 > >>list has a unique ID as an attribute, such that no other client is goin= > > g=20 > >>to choose the same id. Secondly, make sure your schema is such that the= > > =20 > >>path from the document root to this list is "unique". That means that=20 >>its not possible to change the document such that this path expression=20 >>remains valid, but points to a different list. This is typically done b= > > y=20 > >>making each element in the path mandatory to appear in the document, or= > > =20 > >>if its not mandatory, is identified by a unique attribute that would no= > > t=20 > >>be re-assigned. >>=20 >>Any objections? >>=20 >>Thanks, >>Jonathan R. >>=20 > > > When I implemented XCAP resource-lists, I have used entry-nodes to > represent other users with some additional information and then I have > added corresponding entry-ref's to subcribeable lists e.g. "friends", > "home", etc... So, it happens easily that if you e.g. remove a user you > have to do multiple deletes or if you change user-names (which I used to > use as keys) you have to change several entry-ref's. From the clients > perspective, it is far easier (and cleaner) if I can do these changes > with atomic conditional requests rather than doing either safe multiple > single requests in sequence or IMO ugly blind pipelined requests. In this specific case, though, the entry-ref might point to an entry in a different document altogether. Multiple-inserts can only take place within the same document, so a client probably needs to do this as multiple operations anyway. -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-bounces@ietf.org Tue Jun 29 18:10:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01182 for ; Tue, 29 Jun 2004 18:10:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQoS-00058I-8g for simple-archive@ietf.org; Tue, 29 Jun 2004 18:10:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQl5-000452-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:07:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQg1-0002ZB-00; Tue, 29 Jun 2004 18:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQYE-0005s4-IM; Tue, 29 Jun 2004 17:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQMe-0001hr-PP for simple@megatron.ietf.org; Tue, 29 Jun 2004 17:42: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 RAA26179 for ; Tue, 29 Jun 2004 17:42:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQMd-0006Bh-EK for simple@ietf.org; Tue, 29 Jun 2004 17:42:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQ6b-0002qg-00 for simple@ietf.org; Tue, 29 Jun 2004 17:25:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfPjf-00066h-00 for simple@ietf.org; Tue, 29 Jun 2004 17:01:47 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5TL1Ybo002573; Tue, 29 Jun 2004 17:01:34 -0400 (EDT) Message-ID: <40E1D89A.5030503@dynamicsoft.com> Date: Tue, 29 Jun 2004 17:01:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Biot Olivier Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple ele ments References: <6B546A602AD2D211BFF00008C7A428890B1E283C@hrtades2.atea.be> In-Reply-To: <6B546A602AD2D211BFF00008C7A428890B1E283C@hrtades2.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Biot Olivier wrote: > Wouldn't it be simpler to use HTTP POST for multiple insertions as > idempotence cannot be guaranteed? Additionally, atomic operations could be > implemented by using HTTP POST and some "envelope" media type instead of the > purely Etag-based approach as described today. There are other, much bigger problems here. Most notably, POST is a sure sign that you are really defining a new protocol (and indeed, in this case, a database protocol), and that HTTP is probably not the right match. -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-bounces@ietf.org Tue Jun 29 18:12:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01619 for ; Tue, 29 Jun 2004 18:12:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQqZ-0005hj-8O for simple-archive@ietf.org; Tue, 29 Jun 2004 18:12:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQov-0005EF-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:11:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQm9-0004BE-00; Tue, 29 Jun 2004 18:08:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQbB-0006h6-Gl; Tue, 29 Jun 2004 17:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQNj-00027y-JL for simple@megatron.ietf.org; Tue, 29 Jun 2004 17: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 RAA26384 for ; Tue, 29 Jun 2004 17:43:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQNi-0006Tj-3o for simple@ietf.org; Tue, 29 Jun 2004 17:43:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQ92-0003Gs-00 for simple@ietf.org; Tue, 29 Jun 2004 17:28:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfPnl-0006oK-00 for simple@ietf.org; Tue, 29 Jun 2004 17:06:01 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5TL5hbo002577; Tue, 29 Jun 2004 17:05:48 -0400 (EDT) Message-ID: <40E1D994.3010608@dynamicsoft.com> Date: Tue, 29 Jun 2004 17:05:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Simple] XCAP Issue 4 Interim Summary: document to element separator References: <1086872390.7949.36.camel@xitami.research.nokia.com> <40C7FC2A.5080405@dynamicsoft.com> <1086872390.7949.36.camel@xitami.research.nokia.com> <5.1.0.14.0.20040617094705.02312ea8@localhost> In-Reply-To: <5.1.0.14.0.20040617094705.02312ea8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alright, lets just do the ~~ and be done with this issue. -Jonathan R. Joel M. Halpern wrote: > To rephrase my concern slightly, I am not particularly concerned about > transparent (or other) proxies in the communication path rewriting the ~ > to be the users home directory. > I am concerned about the case where the HTTP processing logic in the > target, before it hands to URI off to the XCAP logic, may replace the ~ > with the users home directory. > I am not sure how likely that is. > It seems extremely unlikely that such logic would replace ~~ with anything. > Aesthetically, I prefer a single ~. For safety, I am inclined towards > the double. > > Yours, > Joel > > At 06:52 AM 6/17/2004 -0400, Jonathan Rosenberg wrote: > >> We need to keep in mind that XCAP is all about defining the structure >> of a URI and defining the resource it identifies. Thus, its not like >> you are going to see arbitrary URIs. We can simply mandate that no >> path in the directory have the name "~~". The concern was around the >> possibility of transparent proxies and other nasties that would not >> know about xcap, and would rewrite the "~" in a URI to the home >> directory of a user. This idea was that they wouldn't rewrite a "~~". >> >> If we don't worry about that case (transparent proxies rewriting >> URIs), then we can even use the "~" safely, just by mandating that the >> XCAP server never allow "~" as a part of the path. >> >> Honestly, I'd rather do that and just use the single tilde. >> >> -Jonathan R. > > > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 29 18:17:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02313 for ; Tue, 29 Jun 2004 18:17:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQv4-0007eA-65 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:17:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQuJ-0007HM-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 18:16:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfQtf-0006rj-00; Tue, 29 Jun 2004 18:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQbT-0006qd-RA; Tue, 29 Jun 2004 17:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfQOk-0002Vp-4f for simple@megatron.ietf.org; Tue, 29 Jun 2004 17:44: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 RAA26546 for ; Tue, 29 Jun 2004 17:44:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQOi-0006cR-MZ for simple@ietf.org; Tue, 29 Jun 2004 17:44:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQBQ-0003zk-00 for simple@ietf.org; Tue, 29 Jun 2004 17:30:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfPsF-00002W-00 for simple@ietf.org; Tue, 29 Jun 2004 17:10:39 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5TLAQbo002580; Tue, 29 Jun 2004 17:10:26 -0400 (EDT) Message-ID: <40E1DAB2.2060802@dynamicsoft.com> Date: Tue, 29 Jun 2004 17:10:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions References: <475FF955A05DD411980D00508B6D5FB00C614259@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C614259@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Of the folks participating in the list discussion, there was nearly an even split between those who wanted the feature, and those who don't. I'm personally on the fence. Objectively weighing the arguments that were made, when you get down to the details, the complexity of this particular feature is actually small (I sent pseudocode to demonstrate that). It buys us useful functions. It would actually make the spec smaller, since I could exclude a lot of text on schema design guidelines which would otherwise need to be there. So, the conclusion would seem to lean towards including it. I'd really, really like to close on this issue, so we can finish this specification, as its long overdue. So, is there anyone who simply cannot deal with the inclusion of this feature in the spec? Thanks, Jonathan R. Drage, Keith (Keith) wrote: > My view at the moment is "keep it simple" and not do positional > insertions in XCAP. > > If there is a need for an enhanced capability, then there would > appear to be other ways of modifying XML documents that could be > brought into play outside the use of XCAP, and I suspect that at the > most, IETF SIMPLE should just allow these other mechanisms to be > used. > > That keeps XCAP at a low level where the majority of user > applications will work perfectly well, and leaves the high level > stuff to the 1% that can use something else to do the more > sophisticated things. > > Additionally, to do some of these high level things, I am not sure I > would start from XCAP in the first place. > > regards > > Keith > > >> -----Original Message----- From: Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: 17 June 2004 13:07 To: >> hisham.khartabil@nokia.com Cc: simple@ietf.org Subject: Re: >> [Simple] XCAP Issue 2 Interim Summary: Positional Insertions >> >> >> >> >> hisham.khartabil@nokia.com wrote: >> >> >>> Jonathan, >>> >>> Thanks for the analysis. >>> >>> Reading your analysis actually brings me to the opposite >>> conclusion to the one you made. That is, we need positional >>> insertions. There are so many rules, restriction, and guide >>> lines that need to be educated to current and future designers of >>> XCAP friendly schemas. Wouldn't it be a much better investment if >>> we allow positional insertions now and avoid schema misdesign? >> >> I don't think any of the guidelines represent a schema mis-design. >> >> >>> You haven't explicitly listed the issues with positional >>> insertions, but instead you listed the problems that it solves. >>> Can you please educate the rest of us what the real problems are >>> with positional insertions? >> >> It was just complexity. Positional insertions would require us to >> support multiple predicates (i.e., more than one [] rule). We could >> restrict it to just two in our case, and indeed, restrict the >> first predicate to be a positional selector only. I think that >> might help the complexity a bit. However, there is definitely more >> logic and code required to support it than not. How much exactly? >> Depends on the implementation. I'll send a separate note in the >> next day or so with a pseudo-code view of what a minimal >> implementation would be, so folks can get a sense of it. >> >> The meta-issue was that the whole idea with xcap is that what we >> are generally doing is reading and writing a document from a server >> (like a buddy list), but sometimes, you need to read or write a >> piece of it as an optimization, so we have the notion of >> sub-document addressing. When you view the design goal as reading >> and writing of entire documents with sub-document operations as a >> performance optimization, things like positional inserts teeter on >> the boundary between this view, and the view of xcap as an XML >> database protocol. I think that, if we are defining an XML database >> protocol, we would probably start from a different approach, along >> the lines of XUpdate. >> >> I must say that, on the issue of positional inserts, I am on the >> fence. I do see the "keep it barebones simple" argument, especially >> as it relates to the view of xcap as an optimization around reading >> and writing of documents. On the other hand, from a code >> perspective, I don't think positional inserts is actually that >> complicated, and it does, as Hisham pointed out, remove a lot of >> "schema design guidelines" that I would otherwise need to introduce >> to deal with it. >> >> Comments from others? Even a "do positional inserts" or "dont do >> it" response is helpful. >> >> 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-bounces@ietf.org Tue Jun 29 22:59:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16774 for ; Tue, 29 Jun 2004 22:59:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfVK1-0007LE-EQ for simple-archive@ietf.org; Tue, 29 Jun 2004 22:59:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfVJ2-0006yj-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 22:58:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfVI4-0006Gd-00; Tue, 29 Jun 2004 22:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfVEM-0004ZE-Fz; Tue, 29 Jun 2004 22:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfVBT-00049t-EY for simple@megatron.ietf.org; Tue, 29 Jun 2004 22:50: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 WAA16647 for ; Tue, 29 Jun 2004 22:50:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfVBR-00044l-J9 for simple@ietf.org; Tue, 29 Jun 2004 22:50:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfVAZ-0003hy-00 for simple@ietf.org; Tue, 29 Jun 2004 22:49:56 -0400 Received: from smtp104.mail.sc5.yahoo.com ([66.163.169.223]) by ietf-mx with smtp (Exim 4.12) id 1BfV9y-0003Km-00 for simple@ietf.org; Tue, 29 Jun 2004 22:49:18 -0400 Received: from unknown (HELO cranberry) (seancolson@4.41.208.58 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 30 Jun 2004 02:48:03 -0000 From: "Sean Olson" To: "'Vijay Hampapur Hampapur Parthasarathy'" , "'Ben Campbell'" Subject: RE: [Simple] MSRP Boundary header Date: Tue, 29 Jun 2004 19:48:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcReFm6sMrzl7OHvTqSWKTOncNB4UQAAGPMgAA0iWGA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-Id: Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: seancolson@yahoo.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=FORGED_YAHOO_RCVD, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Why not allow both methods? It seems clear that there are probably two common use cases: 1) Simple, brief messages as in today's IM conversations 2) Larger, more complex, richer messages as forseen in 3G and other environments For (1), the content length is usually small and certainly known in advance. There isn't much point in chunking up the content and it's a bit overkill to have to parse for a content boundary For (2), chunking makes sense and in some streaming applications, it make be impossible to know the TOTAL content length in advance Both can easily be accommodated with the same protocol much as is done with HTTP. If the Content-Length is present, it represent the total message size and there is no need for chunking If the Content-Length is not present, use chunking/boundary delimiter to stream the content The choice of which to use will typically be made based on content size and is a simple implementation decision. For example, for messages larger than 2K, it probably makes sense to chunk up the content. Otherwise, why not use a simpler approach. Of course, you can combine the two choices into a hybrid approach. Use a byte-range header plus a end-of-message header. For the simple case (1), you set the byte-range to represent the entire content length and set the end-of-message header to true. For the more complex case (2), you chunk up the content and use the byte-range to indicate the size of the chunk, the end-of-message header to indicate continuations, and (if desired)a Boundary header to allow mid-chunk termination of the message. Of course, if you choose the chunk size appropriately, it should be pretty rare that you would want to terminate the message mid-chunk Bottom line, I don't see why applications that fall into category 1 should pay the overhead of applications that fall into category 2 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Vijay Hampapur Hampapur Parthasarathy Sent: Tuesday, June 29, 2004 1:27 PM To: Ben Campbell Cc: simple@ietf.org Subject: RE: [Simple] MSRP Boundary header But the Stack that is sending this stream out needs to packetise it at some point, at that point in time we do know the exact length of the amount we are sending in this one packet and that can be included as a header. And if you are talking about relays that need to rechunk messages for slow b/w links, then they already know how much of the message has been received and what size of chunk is acceptable on this segment in order to split it up. Maybe I don't fully understand the specific streamin application you have in mind where this kind of unknown length upfront would be required. Thanks Vijay -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Tuesday, June 29, 2004 1:19 PM To: Vijay Kishen Hampapur Parthasarathy Cc: Aditya Bhasin; simple@ietf.org Subject: Re: [Simple] MSRP Boundary header That works if you abort message content between chunks. We are talking about either aborting or splitting a chunk in mid-stream. And the 06 draft already has something similar to your idea of an ENDOFMESSAGE flag in the continuation flag. The problem if, if you put a content-length at the front of a message, you obviously have to know how long that message is in advance. If I need to interrupt a chunk at some arbitrary point in its transmission, I have violated that knowledge. Vijay Hampapur Hampapur Parthasarathy wrote: > Why cannot this be handled with a content length header that specifies > the length of this chunk. And another header, say an ENDOFMESSAGE > header bool, that specifies if the message is completely done or more > pieces are present. This way the logic to parse would not need to look > thro the entire message before sending (in order to ensure the > boundary characters arent present) and to parse when reading to see > where the current chunk (/message) ends > > Vijay > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf Of Ben Campbell > Sent: Monday, June 28, 2004 3:47 PM > To: Aditya Bhasin > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > The ability to handle large content has been a generally accepted > requirement. The entire chunking mechanism is there due to this > requirement. > > I do not understand what you mean by "being close to the application". > There a a number of ways an application could talk to the MSRP layer. > For an absurdly trivial example, you could simply pipe output from an > app, and have MSRP recognize the end-of-file. > > Aditya Bhasin wrote: > > >>What applications are being targeted for this to be an issue? >> >>The size of the content will have to be extremely large and the >>application pretty close to a streaming application to be able to >>insert an ending boundary delimiter. >> >>Sorry late to the discussions and only trying to understand what is >>driving this requirement. >> >>thx >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, June 28, 2004 3:30 PM >>To: Aditya Bhasin >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP Boundary header >> >>If you use message-length for framing purposes, then once you have >>sent the message-length value, you have to send that many bytes. If >>you don't, the peer cannot tell when the current message ends and the >>next one starts. Once the peer loses track of framing in this way, >>framing is lost for the entire connection. >> >>We could probably fix this with some sort of sync protocol, but that >>would be more complex than just going to a delimiter approach to >>framing, which is exactly what the boundary is. >> >> >> >>Aditya Bhasin wrote: >> >> >> >>>Ben, >>> >>>Could you explain this a little more. >>> >>>Thx >>> >>>aditya >>> >>>-----Original Message----- >>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>Behalf >> >>Of >> >> >>>Ben Campbell >>>Sent: Monday, June 28, 2004 2:04 PM >>>To: Murty Dasari >>>Cc: simple@ietf.org >>>Subject: Re: [Simple] MSRP Boundary header >>> >>>The reason is, we added a requirement to be able abort a message >>>without destroying framing for the TCP connection. The boundary >>>approach has that property, content-length does not. >>> >>>Murty Dasari wrote: >>> >>> >>> >>> >>>>Hello, >>>> >>>> >>>> >>>>I've a question about MSRP (based on >>>>draft-ietf-simple-message-sessions-06.txt) "Closing" field. >>>> >>>> >>>> >>>>What is the need for a "Closing" field? >>>> >>>> >>>> >>>>Can't we use "Content-Length" similar to HTTP for determining the >>>>message body length? If this is there for "Continuation-Flag" then >>>>probably we can have another header that indicates continuation > > status. > >>>>Though it might not be lot of work to determine the "closing" tag, >>>>it > > >>>>might be easy for the relays and clients to retrieve the message >>>>body > > >>>>based on content-length header; further, we don't have to add >>>>restrictions on presence of "boundary" in the message body in this > > case. > >>>> >>>> >>>>This question might have brought-up/answered earlier, but I couldn't >>>>find out from the archives. Appreciate any comments. >>>> >>>> >>>> >>>>Thanks for your time. >>>> >>>>- Murty >>>> >>>> >>>> >>>> >>>>-------------------------------------------------------------------- >>>>- >>>>--- >>>> >>>>_______________________________________________ >>>>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-bounces@ietf.org Tue Jun 29 23:33:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17725 for ; Tue, 29 Jun 2004 23:33:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfVr4-0004Y2-Mm for simple-archive@ietf.org; Tue, 29 Jun 2004 23:33:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfVqC-0004AY-00 for simple-archive@ietf.org; Tue, 29 Jun 2004 23:32:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfVpc-0003mf-00; Tue, 29 Jun 2004 23:32:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfVm5-0001eO-LQ; Tue, 29 Jun 2004 23:28:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfVhK-0000pe-2M for simple@megatron.ietf.org; Tue, 29 Jun 2004 23:23:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17433 for ; Tue, 29 Jun 2004 23:23:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfVhH-0000iq-Ko for simple@ietf.org; Tue, 29 Jun 2004 23:23:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfVgL-0000M4-00 for simple@ietf.org; Tue, 29 Jun 2004 23:22:46 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BfVfU-0007QC-00 for simple@ietf.org; Tue, 29 Jun 2004 23:21:52 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5U3LD57009171; Tue, 29 Jun 2004 20:21:13 -0700 (PDT) Received: from [67.169.32.79] (vpn-10-50-16-97.qualcomm.com [10.50.16.97]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5U3LABl029483; Tue, 29 Jun 2004 20:21:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Tue, 29 Jun 2004 20:21:09 -0700 To: seancolson@yahoo.com, "'Vijay Hampapur Hampapur Parthasarathy'" , "'Ben Campbell'" From: Ted Hardie Subject: RE: [Simple] MSRP Boundary header Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 7:48 PM -0700 6/29/04, Sean Olson wrote: >Why not allow both methods? >It seems clear that there are probably two common use cases: > >1) Simple, brief messages as in today's IM conversations >2) Larger, more complex, richer messages as forseen in 3G and other >environments Sorry to ask such a potentially silly question, but aren't the messages in case one to be handled by SIP/SIMPLE, rather than MSRP? regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 01:53:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23258 for ; Wed, 30 Jun 2004 01:53:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfY2g-0004R7-B7 for simple-archive@ietf.org; Wed, 30 Jun 2004 01:53:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfY1t-00043g-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 01:53:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfY1L-0003eS-00; Wed, 30 Jun 2004 01:52:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfXvy-0002iA-7k; Wed, 30 Jun 2004 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfXqz-0001PO-Rm for simple@megatron.ietf.org; Wed, 30 Jun 2004 01: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 BAA22811 for ; Wed, 30 Jun 2004 01:41:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfXqx-0007UY-Sf for simple@ietf.org; Wed, 30 Jun 2004 01:41:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfXpz-00077V-00 for simple@ietf.org; Wed, 30 Jun 2004 01:40:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BfXpR-0006jP-00 for simple@ietf.org; Wed, 30 Jun 2004 01:40:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Jun 2004 22:40:04 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i5U5dkRs018846; Tue, 29 Jun 2004 22:39:46 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn2-1303.cisco.com [10.21.117.23]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQE43288; Tue, 29 Jun 2004 22:39:44 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 29 Jun 2004 20:07:51 -0700 Subject: Re: [Simple] MSRP Boundary header From: Cullen Jennings To: Vijay Hampapur Hampapur Parthasarathy , Ben Campbell Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit If the largest chunk you ever sent was 2k, then you can probably get away with this knowing before you send the chunk if you can send the whole thing or not. This 2k number is debatable but it's close enough for discussions sake. However, this results in a less efficient use of the bandwidth because of protocol overhead if you want to sent 100k. So the idea is to allow a 100k block to be sent and if it needs to be interrupted, interrupt it. If the 2k number is smaller than 2k (as some people have suggested) this becomes even more important. You do not need to scan the whole message ahead of time to see if it contains the boundary. You can incrementally scan and if you find the boundary, interrupt just before it occurs and start sending with a new boundary. This also allows you to build streaming relays that just send as they receive and interrupt only when needed. You can also build store and forward relays if you want. There is quite a bit of discussion on this "framing" issues in the archives. On 6/29/04 1:26 PM, "Vijay Hampapur Hampapur Parthasarathy" wrote: > But the Stack that is sending this stream out needs to packetise it at > some point, at that point in time we do know the exact length of the > amount we are sending in this one packet and that can be included as a > header. And if you are talking about relays that need to rechunk > messages for slow b/w links, then they already know how much of the > message has been received and what size of chunk is acceptable on this > segment in order to split it up. > > Maybe I don't fully understand the specific streamin application you > have in mind where this kind of unknown length upfront would be > required. > > Thanks > Vijay > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, June 29, 2004 1:19 PM > To: Vijay Kishen Hampapur Parthasarathy > Cc: Aditya Bhasin; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > That works if you abort message content between chunks. We are talking > about either aborting or splitting a chunk in mid-stream. And the 06 > draft already has something similar to your idea of an ENDOFMESSAGE flag > in the continuation flag. > > The problem if, if you put a content-length at the front of a message, > you obviously have to know how long that message is in advance. If I > need to interrupt a chunk at some arbitrary point in its transmission, I > have violated that knowledge. > > Vijay Hampapur Hampapur Parthasarathy wrote: > >> Why cannot this be handled with a content length header that specifies > >> the length of this chunk. And another header, say an ENDOFMESSAGE >> header bool, that specifies if the message is completely done or more >> pieces are present. This way the logic to parse would not need to look > >> thro the entire message before sending (in order to ensure the >> boundary characters arent present) and to parse when reading to see >> where the current chunk (/message) ends >> >> Vijay >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf Of Ben Campbell >> Sent: Monday, June 28, 2004 3:47 PM >> To: Aditya Bhasin >> Cc: simple@ietf.org >> Subject: Re: [Simple] MSRP Boundary header >> >> The ability to handle large content has been a generally accepted >> requirement. The entire chunking mechanism is there due to this >> requirement. >> >> I do not understand what you mean by "being close to the application". > >> There a a number of ways an application could talk to the MSRP layer. >> For an absurdly trivial example, you could simply pipe output from an >> app, and have MSRP recognize the end-of-file. >> >> Aditya Bhasin wrote: >> >> >>> What applications are being targeted for this to be an issue? >>> >>> The size of the content will have to be extremely large and the >>> application pretty close to a streaming application to be able to >>> insert an ending boundary delimiter. >>> >>> Sorry late to the discussions and only trying to understand what is >>> driving this requirement. >>> >>> thx >>> -----Original Message----- >>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>> Sent: Monday, June 28, 2004 3:30 PM >>> To: Aditya Bhasin >>> Cc: simple@ietf.org >>> Subject: Re: [Simple] MSRP Boundary header >>> >>> If you use message-length for framing purposes, then once you have >>> sent the message-length value, you have to send that many bytes. If >>> you don't, the peer cannot tell when the current message ends and the >>> next one starts. Once the peer loses track of framing in this way, >>> framing is lost for the entire connection. >>> >>> We could probably fix this with some sort of sync protocol, but that >>> would be more complex than just going to a delimiter approach to >>> framing, which is exactly what the boundary is. >>> >>> >>> >>> Aditya Bhasin wrote: >>> >>> >>> >>>> Ben, >>>> >>>> Could you explain this a little more. >>>> >>>> Thx >>>> >>>> aditya >>>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf >>> >>> Of >>> >>> >>>> Ben Campbell >>>> Sent: Monday, June 28, 2004 2:04 PM >>>> To: Murty Dasari >>>> Cc: simple@ietf.org >>>> Subject: Re: [Simple] MSRP Boundary header >>>> >>>> The reason is, we added a requirement to be able abort a message >>>> without destroying framing for the TCP connection. The boundary >>>> approach has that property, content-length does not. >>>> >>>> Murty Dasari wrote: >>>> >>>> >>>> >>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I've a question about MSRP (based on >>>>> draft-ietf-simple-message-sessions-06.txt) "Closing" field. >>>>> >>>>> >>>>> >>>>> What is the need for a "Closing" field? >>>>> >>>>> >>>>> >>>>> Can't we use "Content-Length" similar to HTTP for determining the >>>>> message body length? If this is there for "Continuation-Flag" then >>>>> probably we can have another header that indicates continuation >> >> status. >> >>>>> Though it might not be lot of work to determine the "closing" tag, >>>>> it >> >> >>>>> might be easy for the relays and clients to retrieve the message >>>>> body >> >> >>>>> based on content-length header; further, we don't have to add >>>>> restrictions on presence of "boundary" in the message body in this >> >> case. >> >>>>> >>>>> >>>>> This question might have brought-up/answered earlier, but I couldn't > >>>>> find out from the archives. Appreciate any comments. >>>>> >>>>> >>>>> >>>>> Thanks for your time. >>>>> >>>>> - Murty >>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> - >>>>> --- >>>>> >>>>> _______________________________________________ >>>>> 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-bounces@ietf.org Wed Jun 30 01:54:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23302 for ; Wed, 30 Jun 2004 01:54:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfY3b-0004ok-Po for simple-archive@ietf.org; Wed, 30 Jun 2004 01:54:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfY2j-0004Ro-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 01:54:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfY2J-000436-00; Wed, 30 Jun 2004 01:53:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfXvy-0002iQ-Or; Wed, 30 Jun 2004 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfXr0-0001PQ-LN for simple@megatron.ietf.org; Wed, 30 Jun 2004 01:41: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 BAA22814 for ; Wed, 30 Jun 2004 01:41:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfXqy-0007Ud-Ij for simple@ietf.org; Wed, 30 Jun 2004 01:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfXq0-00077d-00 for simple@ietf.org; Wed, 30 Jun 2004 01:40:53 -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 1BfXpT-0006ji-00 for simple@ietf.org; Wed, 30 Jun 2004 01:40:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Jun 2004 22:43:33 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5U5dlSc001775; Tue, 29 Jun 2004 22:39:47 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn2-1303.cisco.com [10.21.117.23]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQE43290; Tue, 29 Jun 2004 22:39:45 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 29 Jun 2004 21:14:50 -0700 Subject: Re: [Simple] Re: MSRP: Max message size indication From: Cullen Jennings To: Ben Campbell , "Christer Holmberg (JO/LMF)" Message-ID: In-Reply-To: <40E0780A.8060703@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org, Paul H Kyzivat , alex.audu@alcatel.com, cboulton@ubiquity.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Trying to be more specific. The SDP parameter is a max size the person receiving the SDP should send. It is the max size of the message not the chunk. The receiver SHOULD NOT send messages larger than this. It is the size of the content not the size of the message. Cullen, And if it is set to 1 it means you are in character by character T.140 mode :-) The previos line is a joke I'm not suggesting that On 6/28/04 12:56 PM, "Ben Campbell" wrote: > I believe the conclusion is to allow signaling max size you wish to > receive, but not to signal the max you intend to send. >=20 > Christer Holmberg (JO/LMF) wrote: >=20 >> Hi, >>=20 >> So, do we have some kind of conclusion on this? >>=20 >> Some people have asked for use-cases, and scenarios where this can be us= eful, >> and I think a number of those have now been presented. >>=20 >> Regards, >>=20 >> Christer Holmberg >> Ericsson Finland >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 15. kes=E4kuuta 2004 2:04 >>> To: alex.audu@alcatel.com >>> Cc: Adam Roach; 'hisham.khartabil@nokia.com'; >>> simple@ietf.org; Christer >>> Holmberg (JO/LMF); cboulton@ubiquity.com; Ben Campbell >>> Subject: Re: [Simple] Re: MSRP: Max message size indication >>>=20 >>>=20 >>>=20 >>>=20 >>> Alex Audu wrote: >>>=20 >>>> I think there is great value in end-point being able to signal the >>>> maximum size of data it is >>>> willing /able to accept at a time. This information could >>>=20 >>> be used by the=20 >>>=20 >>>> sender to, for example >>>> send a less memory intensive version of say an image, >>>=20 >>> instead of a full >>>=20 >>>> blown memory hungry >>>> version. This will allow the information to be communicated with a >>>> decreased risk of truncation >>>> at first try. That makes for a more efficient communication (than >>>> without this feature). >>>=20 >>> This is the most compelling argument for this feature that I >>> have seen. >>>=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-bounces@ietf.org Wed Jun 30 02:07:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00735 for ; Wed, 30 Jun 2004 02:07:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfYFK-0001cJ-L7 for simple-archive@ietf.org; Wed, 30 Jun 2004 02:07:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfYEN-0001EI-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 02:06:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfYDi-0000ow-00; Wed, 30 Jun 2004 02:05:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfY5W-0004Gn-LW; Wed, 30 Jun 2004 01:56:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfXyo-00037A-BP for simple@megatron.ietf.org; Wed, 30 Jun 2004 01:49:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23140 for ; Wed, 30 Jun 2004 01:49:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfXym-0002rN-CN for simple@ietf.org; Wed, 30 Jun 2004 01:49:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfXxz-0002Ty-00 for simple@ietf.org; Wed, 30 Jun 2004 01:49:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BfXx9-0001wb-00 for simple@ietf.org; Wed, 30 Jun 2004 01:48:15 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i5U5dkRu018846; Tue, 29 Jun 2004 22:39:48 -0700 (PDT) Received: from [10.0.1.4] (sjc-vpn2-1303.cisco.com [10.21.117.23]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AQE43289; Tue, 29 Jun 2004 22:39:45 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 29 Jun 2004 20:46:16 -0700 Subject: Re: [Simple] MSRP: Surpression of duplicates From: Cullen Jennings To: , , Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CD7@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On 6/29/04 12:41 AM, "hisham.khartabil@nokia.com" wrote: > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf >> Of ext Ben Campbell >> Sent: 28.June.2004 23:36 >> To: Simple WG >> Subject: [Simple] MSRP: Surpression of duplicates >> >> >> The working group has gone round and round on whether (and how) we >> handle worry about the surpression of duplicate messages, in >> situations >> where a failure occurs, and the sender chooses to re-send >> content on a >> new session. >> >> Since we have introduced the concept of a MessageID, this >> becomes fairly >> easy to accomplish. If we specify the MessageID to be >> globally unique, >> or even just very likely to re-occur in a relatively short >> time period, >> then the receive can simply watch for duplicate messageIDs. The >> receiver's action upon receiving a duplicate would be entirely up to >> local policy (although simply displaying the duplicate to the user >> without any warning of duplication would be a bad choice.) >> >> This approach only works for detecting whole-content >> duplication, rather >> than chunk duplication. We recommend that chunks of a given >> message not >> be spread across more than one session. > > I don't like this recommendation. If I'm sending you a 5GB file in chunks and > the session breaks, then I would like to continue where I left off. But I > guess it doesn't necessarily have to be the same message ID. I got lost on this - I think I agree with Hisham - I think the mechanims does work for chunk duplicate - you find a message using the messageId and if you already have data for the range of data in the chunk, you can ignore the part that is an overlap. Perhaps that is what you say in the next paragraph > >> Within any given session, the >> chunking mechanism already provides a way to notice >> duplication--you can >> watch for byte-range overlaps. >> >> If there are no subtantive objections to the approach, the next draft >> version will describe the details. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 04:21:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01256 for ; Wed, 30 Jun 2004 04:21:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfaKz-0000mE-T3 for simple-archive@ietf.org; Wed, 30 Jun 2004 04:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfaJy-0000Mh-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 04:19:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfaJ1-0007OY-00; Wed, 30 Jun 2004 04:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfaCn-00058N-K6; Wed, 30 Jun 2004 04:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfa5Y-0003eD-Ai for simple@megatron.ietf.org; Wed, 30 Jun 2004 04:05: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 EAA00451 for ; Wed, 30 Jun 2004 04:05:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfa5W-0002CG-5j for simple@ietf.org; Wed, 30 Jun 2004 04:05:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfa4T-0001o2-00 for simple@ietf.org; Wed, 30 Jun 2004 04:03:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Bfa3a-0001O1-00 for simple@ietf.org; Wed, 30 Jun 2004 04:03:02 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U82tJ27394; Wed, 30 Jun 2004 11:02:55 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 11:02:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5U82DMm030990; Wed, 30 Jun 2004 11:02:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00bhu5qY; Wed, 30 Jun 2004 11:02:12 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U820H02285; Wed, 30 Jun 2004 11:02:00 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 11:02:00 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 11:01:59 +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] Using MSRP for real time text conversation Date: Wed, 30 Jun 2004 11:01:59 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CE3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Using MSRP for real time text conversation Thread-Index: AcReHtGs/MD949cQRUWSPULgrUd8qgAWEB1g To: , , X-OriginalArrivalTime: 30 Jun 2004 08:01:59.0949 (UTC) FILETIME=[8558C3D0:01C45E78] Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, toip@snowshore.com, adam@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I am not willing to delay the completion of MSRP for this. However, I am = not going to kill the idea of using MSRP for real-time text. I believe = it is worth considering, but after the base MSRP spec has passed. It sounds reasonable to have real-time text as an implementation choice = for clients where users can flick a switch to turn it on or off. Having = a 500ms buffer seems to aid in solving the character-by-character = issues.=20 This requires 1 of 2 things: specify the behaviour in a way that enables = one side (the sender) to support real-time text while the other can be = oblivious of that. Or, specify an SDP negotiation for it. Again, I am against the idea of having the solution for this appear in = the current MSRP spec as it will cause delays. We have external = standardisation bodies awaiting this and it so close to completion now I = would hate to delay it any further. Regards, Hisham=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Gunnar Hellstrom > Sent: 29.June.2004 22:58 > To: Dean Willis; Ben Campbell > Cc: STF267; Adam Roach; toip@snowshore.com; simple@ietf.org > Subject: RE: [Simple] Using MSRP for real time text conversation >=20 >=20 > Thanks for good summaries and questions. > Comments inline, >=20 >=20 > >Re-adding my comments to this branch of the thread: > > > >Dean Willis wrote: > > > >> > >> > >> Adam Roach wrote: > >> > >>> Gunnar: > >>> > >>> I'm very confused. Why do you want to use MSRP for T.140 text? You > >>> don't *need* MSRP to have T.140 conversations. You just carry them > >>> like any other real-time streams -- isn't that the point=20 > of RFC 2793? > >>> > >> > >> Darn these cross-list discussions. You and Hisham seem to=20 > have missed > >> the first forty messages in this thread, and reacted with=20 > justifiable > >> surprise. > >> > >> Recap, for those who missed the first season of our serial drama: > >> > >> Gunnar does NOT "want" to use MSRP -- he proposed using=20 > T.140 exactly as > >> you discussed it above. He also wants real-time text in=20 > every phone and > >> messaging device produced, for 100% availability, a goal=20 > that I find > >> agreeable. > >> > >> However, I don't want to use T.140. Emulating reliability=20 > by requiring > >> multiple transmissions of every character without regard for real > >> network conditions is a horrible violation of the=20 > principles of RFC2914. >=20 > It is not T.140 you are suspicious to, it is to use the RTP=20 > packetisation text/t140 as > specified in rfc2793 ( and -bis ) that you have doubts about. >=20 > The repetitions are sent together with new characters, and=20 > therefore do not cause any > remarkable increase in load. >=20 > The unusual characteristics of this rtp packetization makes=20 > it not as horrible as you seem > to think. >=20 > It is not a true character-by-character transmission. All=20 > characters typed during a > buffering interval are transmitted together. The default=20 > buffering time is 300 ms. If no > data is available for transmission, no packet is sent. >=20 > User spend often more time thinking and reading than they=20 > spend typing. So, studying max > values does not give you a good view of the real ( low ) load. >=20 > The additional words about actions in case of congestion=20 > should be effective. RTCP info > can be the base for increasing buffering time. >=20 > >> > >> So, I raised the question: Could we use a reliable and=20 > 2914-compliant > >> protocol like MSRP to meet the needs of real-time text? We are now > >> discussing this possibility, using MSRP as the baseline. > >> > >> Open questions: > >> > >> 1) Would the user experience be acceptable? > With 300 ms between transmissions if there is data, I would=20 > expect MSRP to behave just as > well as RTP text/t140, assuming that it gets through NAT and=20 > firewalls. >=20 > We saw that the bandwidth seems to be 3 times higher for=20 > MSRP. If we compensate by > increasing buffering time we reach 1 second buffering time,=20 > and that will be regarded too > slow and chunky. 500 ms is the limit. >=20 > >> > >> 2) What is the bandwidth required, relative to T.140? > > > >If you send one char per message, absurdly huge. If you use=20 > some of the > >streaming features of MSRP, this might could be somewhat=20 > mitigated. But > >this would be an extremely constrained and mutant usage of=20 > MSRP as it is > >currently described. > With maximum allowable 500 ms for MSRP it will be 4 kbit/s.=20 > With 300 ms buffering it will > be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a=20 > mobile situation. Otherwise > it is probably OK. We are dealing with calls where it will be=20 > in many cases favourable to > use video and audio as well. > > > >> > >> 3) How much change would this imply for MSRP? > >> > > > >I am assuming the 1 char per message approach is not even on=20 > the table. > >If you use a stream approach, you will need loads of new=20 > rules about how > >to do this, and how to signal you want to do it. > Look at 500 ms buffering instead. > Would you dare to recommend it then? >=20 >=20 > > > >> 4) How will this affect the widepsread availability of=20 > real-time text? > >> Cullen has proposed that if this is simple as a check-box=20 > in the GUI of > >> every MSRP client, then EVERYBODY has eal-time text capability. > >> > > > >I have no opinion on this. The jury is still out on the wide-spread > >acceptance of MSRP. >=20 > I definitely hope that simple and MSRP gets widespread. The=20 > current fragmentation in the I > M world is a severely hampering factor for its message-wise=20 > use. Impossible to procure for > official use, impossible to use for public services. I wish=20 > you all luck with a > standardised protocol to replace the current situation! >=20 > But for its influence on the real time variant, I also want=20 > to listen to the word from the > jury... > > > >> 5) What are the pros and cons of the various approaches=20 > with respect to > >> firewalls and NATs? Clearly TCP has some advantages, and MSRP has > >> relays, but TURN and STUN give us some existing=20 > infrastructure for T.140. >=20 > There are also true SIP aware NAT-routers and firewalls that=20 > handle SIP and RTP well. I do > not know how well they handle MSRP. > >> > >> 6) is there a sufficient perception of value in the=20 > community to justify > >> adding this sort of function to MSRP, or would yet another=20 > protocol be > >> required? > > > >Well, adding this to the MSRP base spec would be long and=20 > painful. I am > >in principle opposed to adding any significant new=20 > requirements to MSRP, > >as it would put at serious risk of never completing it. > Three small things need to be done: > a. Optional real time transmission in 500 ms buffers. > b. MIME declaration of the transmission in a new text/t140p=20 > format that is just the plain > UTF-8 coded T.140 transmission. > c. A request on the receiver to add received text for display=20 > in one window per > transmitting party. >=20 >=20 >=20 > > > >I also don't think that real-time text is in scope, or in=20 > charter, for > >SIMPLE. > > > >Now, if we, or someone else, decide(s) that it makes sense to extend > >MSRP to allow this, I am not strongly opposed, as long as it does not > >disrupt work on the base spec. (I am not by that statement indicating > >that I do thing it makes sense.) > > > Same here, we have to judge the possible outcome of question=20 > 4 above, and balance it > against the influence on already started activities to=20 > specify text/t140 as the way to do > text conversation, emergency etc. >=20 > Gunnar > >> > >> -- > >> Dean > >> > >> _______________________________________________ > >> 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-bounces@ietf.org Wed Jun 30 04:27:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01583 for ; Wed, 30 Jun 2004 04:27:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfaQq-0003Cp-Rd for simple-archive@ietf.org; Wed, 30 Jun 2004 04:27:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfaPt-0002m7-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 04:26:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfaOn-000201-00; Wed, 30 Jun 2004 04:24:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfaGK-0005mO-RU; Wed, 30 Jun 2004 04:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfa8O-0004Im-G7 for simple@megatron.ietf.org; Wed, 30 Jun 2004 04:08: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 EAA00648 for ; Wed, 30 Jun 2004 04:07:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfa8M-0003RC-7n for simple@ietf.org; Wed, 30 Jun 2004 04:07:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfa7Y-00032v-00 for simple@ietf.org; Wed, 30 Jun 2004 04:07:09 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Bfa6Z-0002co-00 for simple@ietf.org; Wed, 30 Jun 2004 04:06:07 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U862N22663; Wed, 30 Jun 2004 11:06:02 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 11:05:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5U85UqL008609; Wed, 30 Jun 2004 11:05:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00v7rT2u; Wed, 30 Jun 2004 11:05:25 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U85IH05075; Wed, 30 Jun 2004 11:05:18 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 11:05:17 +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] Using MSRP for real time text conversation Date: Wed, 30 Jun 2004 11:05:17 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CE4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Using MSRP for real time text conversation Thread-Index: AcReHtGs/MD949cQRUWSPULgrUd8qgAWbRaw To: , , X-OriginalArrivalTime: 30 Jun 2004 08:05:17.0909 (UTC) FILETIME=[FB571050:01C45E78] Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, toip@snowshore.com, adam@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Gunnar Hellstrom > Sent: 29.June.2004 22:58 > To: Dean Willis; Ben Campbell > Cc: STF267; Adam Roach; toip@snowshore.com; simple@ietf.org > Subject: RE: [Simple] Using MSRP for real time text conversation >=20 >=20 > Thanks for good summaries and questions. > Comments inline, >=20 >=20 > >Re-adding my comments to this branch of the thread: > > > >Dean Willis wrote: > > > >> > >> > >> Adam Roach wrote: > >> > >>> Gunnar: > >>> > >>> I'm very confused. Why do you want to use MSRP for T.140 text? You > >>> don't *need* MSRP to have T.140 conversations. You just carry them > >>> like any other real-time streams -- isn't that the point=20 > of RFC 2793? > >>> > >> > >> Darn these cross-list discussions. You and Hisham seem to=20 > have missed > >> the first forty messages in this thread, and reacted with=20 > justifiable > >> surprise. > >> > >> Recap, for those who missed the first season of our serial drama: > >> > >> Gunnar does NOT "want" to use MSRP -- he proposed using=20 > T.140 exactly as > >> you discussed it above. He also wants real-time text in=20 > every phone and > >> messaging device produced, for 100% availability, a goal=20 > that I find > >> agreeable. > >> > >> However, I don't want to use T.140. Emulating reliability=20 > by requiring > >> multiple transmissions of every character without regard for real > >> network conditions is a horrible violation of the=20 > principles of RFC2914. >=20 > It is not T.140 you are suspicious to, it is to use the RTP=20 > packetisation text/t140 as > specified in rfc2793 ( and -bis ) that you have doubts about. >=20 > The repetitions are sent together with new characters, and=20 > therefore do not cause any > remarkable increase in load. >=20 > The unusual characteristics of this rtp packetization makes=20 > it not as horrible as you seem > to think. If it is not as horrible, then can you remind me why we are discussing = using MSRP for real time text? I am confused now since Dean gave the = reason, but you replied saying that reasoning is not entirely true. Thanks, Hisham >=20 > It is not a true character-by-character transmission. All=20 > characters typed during a > buffering interval are transmitted together. The default=20 > buffering time is 300 ms. If no > data is available for transmission, no packet is sent. >=20 > User spend often more time thinking and reading than they=20 > spend typing. So, studying max > values does not give you a good view of the real ( low ) load. >=20 > The additional words about actions in case of congestion=20 > should be effective. RTCP info > can be the base for increasing buffering time. >=20 > >> > >> So, I raised the question: Could we use a reliable and=20 > 2914-compliant > >> protocol like MSRP to meet the needs of real-time text? We are now > >> discussing this possibility, using MSRP as the baseline. > >> > >> Open questions: > >> > >> 1) Would the user experience be acceptable? > With 300 ms between transmissions if there is data, I would=20 > expect MSRP to behave just as > well as RTP text/t140, assuming that it gets through NAT and=20 > firewalls. >=20 > We saw that the bandwidth seems to be 3 times higher for=20 > MSRP. If we compensate by > increasing buffering time we reach 1 second buffering time,=20 > and that will be regarded too > slow and chunky. 500 ms is the limit. >=20 > >> > >> 2) What is the bandwidth required, relative to T.140? > > > >If you send one char per message, absurdly huge. If you use=20 > some of the > >streaming features of MSRP, this might could be somewhat=20 > mitigated. But > >this would be an extremely constrained and mutant usage of=20 > MSRP as it is > >currently described. > With maximum allowable 500 ms for MSRP it will be 4 kbit/s.=20 > With 300 ms buffering it will > be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a=20 > mobile situation. Otherwise > it is probably OK. We are dealing with calls where it will be=20 > in many cases favourable to > use video and audio as well. > > > >> > >> 3) How much change would this imply for MSRP? > >> > > > >I am assuming the 1 char per message approach is not even on=20 > the table. > >If you use a stream approach, you will need loads of new=20 > rules about how > >to do this, and how to signal you want to do it. > Look at 500 ms buffering instead. > Would you dare to recommend it then? >=20 >=20 > > > >> 4) How will this affect the widepsread availability of=20 > real-time text? > >> Cullen has proposed that if this is simple as a check-box=20 > in the GUI of > >> every MSRP client, then EVERYBODY has eal-time text capability. > >> > > > >I have no opinion on this. The jury is still out on the wide-spread > >acceptance of MSRP. >=20 > I definitely hope that simple and MSRP gets widespread. The=20 > current fragmentation in the I > M world is a severely hampering factor for its message-wise=20 > use. Impossible to procure for > official use, impossible to use for public services. I wish=20 > you all luck with a > standardised protocol to replace the current situation! >=20 > But for its influence on the real time variant, I also want=20 > to listen to the word from the > jury... > > > >> 5) What are the pros and cons of the various approaches=20 > with respect to > >> firewalls and NATs? Clearly TCP has some advantages, and MSRP has > >> relays, but TURN and STUN give us some existing=20 > infrastructure for T.140. >=20 > There are also true SIP aware NAT-routers and firewalls that=20 > handle SIP and RTP well. I do > not know how well they handle MSRP. > >> > >> 6) is there a sufficient perception of value in the=20 > community to justify > >> adding this sort of function to MSRP, or would yet another=20 > protocol be > >> required? > > > >Well, adding this to the MSRP base spec would be long and=20 > painful. I am > >in principle opposed to adding any significant new=20 > requirements to MSRP, > >as it would put at serious risk of never completing it. > Three small things need to be done: > a. Optional real time transmission in 500 ms buffers. > b. MIME declaration of the transmission in a new text/t140p=20 > format that is just the plain > UTF-8 coded T.140 transmission. > c. A request on the receiver to add received text for display=20 > in one window per > transmitting party. >=20 >=20 >=20 > > > >I also don't think that real-time text is in scope, or in=20 > charter, for > >SIMPLE. > > > >Now, if we, or someone else, decide(s) that it makes sense to extend > >MSRP to allow this, I am not strongly opposed, as long as it does not > >disrupt work on the base spec. (I am not by that statement indicating > >that I do thing it makes sense.) > > > Same here, we have to judge the possible outcome of question=20 > 4 above, and balance it > against the influence on already started activities to=20 > specify text/t140 as the way to do > text conversation, emergency etc. >=20 > Gunnar > >> > >> -- > >> Dean > >> > >> _______________________________________________ > >> 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-bounces@ietf.org Wed Jun 30 04:40:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02375 for ; Wed, 30 Jun 2004 04:40:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfadM-0000lx-E1 for simple-archive@ietf.org; Wed, 30 Jun 2004 04:40:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfacP-0000Lj-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 04:39:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfabL-0007NY-00; Wed, 30 Jun 2004 04:37:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfaTR-0000B7-6I; Wed, 30 Jun 2004 04:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfaRB-00088D-TU for simple@megatron.ietf.org; Wed, 30 Jun 2004 04:27: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 EAA01636 for ; Wed, 30 Jun 2004 04:27:23 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfaR9-0003FO-Pk for simple@ietf.org; Wed, 30 Jun 2004 04:27:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfaQE-0002oz-00 for simple@ietf.org; Wed, 30 Jun 2004 04:26:27 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BfaPJ-0002Ow-00 for simple@ietf.org; Wed, 30 Jun 2004 04:25:29 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U8PN608169; Wed, 30 Jun 2004 11:25:24 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 11:25:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5U8PDpv032338; Wed, 30 Jun 2004 11:25:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Y8UTPR; Wed, 30 Jun 2004 11:25:11 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U8P9H22864; Wed, 30 Jun 2004 11:25:09 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 11:25:07 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 11:25:07 +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] XCAP Issue 8: Etag Scope Date: Wed, 30 Jun 2004 11:25:06 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CE7@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 8: Etag Scope Thread-Index: AcReH8hFSAHW063BRUmJSmacA0rz9QAWvloQ To: X-OriginalArrivalTime: 30 Jun 2004 08:25:07.0250 (UTC) FILETIME=[C03E1920:01C45E7B] Content-Transfer-Encoding: quoted-printable Cc: drage@lucent.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 29.June.2004 23:16 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: drage@lucent.com; simple@ietf.org > Subject: Re: [Simple] XCAP Issue 8: Etag Scope >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >> -----Original Message----- From: simple-bounces@ietf.org=20 > >> [mailto:simple-bounces@ietf.org]On Behalf Of ext Jonathan Rosenberg > >> Sent: 28.June.2004 14:30 To: Drage, Keith (Keith) Cc: Simple WG=20 > >> Subject: Re: [Simple] XCAP Issue 8: Etag Scope > >>=20 > >>=20 > >>=20 > >>=20 > >> Drage, Keith (Keith) wrote: > >>=20 > >>=20 > >>> It certainly would be useful to see use cases if people > >>=20 > >> think we need > >>=20 > >>> more complicated solutions. > >>=20 > >> I'd also like to understand the use cases for this. Hisham, can you > >> provide some more? > >=20 > >=20 > > There is a requirement where key participants, for example, get the > > privilege to modify the Dial-out list, the security parameters in a > > conference, or add a media stream to the conference. >=20 > Sure. The question, however, is whether, in these cases, its=20 > necessary=20 > to condition these operations on the current values? I was answering the question on whether there are cases that require = multiple users to modify the same piece of XML document. I think you are right that those cases don't need conditioning. /Hisham > So, for=20 > the cases=20 > you mention: >=20 > 1. modify dial-out list: I would imagine in most cases=20 > someone wants to=20 > add or remove a user from these lists. Removal doesn't require=20 > conditioning the DELETE. Adding doesnt require it either; if=20 > you want to=20 > make sure that the user isnt already there, you can do=20 > If-Not-Match: *. >=20 > 2. modify security parameters: Here, I would imagine that the most=20 > common case is merely to *set* them, without regards to=20 > verifying that=20 > someone else hasn't tried to set them since you last checked.=20 > Would it=20 > make a difference if they had? Why not just PUT the whole ? >=20 > 3. adding a media stream: I'm not exactly sure how this works, so I=20 > can't say if it can be done without a conditional operation. >=20 >=20 > I'll also note that if you want to condition it, you still=20 > can; its just=20 > that if someone else has changed one of these other things,=20 > you may need=20 > to refetch the piece you care about. >=20 >=20 > In my mind, the proposed text I sent out was *really*=20 > complicated, and=20 > was meant to make it clear that there is, IMHO, quite a lot=20 > of cost to=20 > this complex scope definitions. >=20 > -Jonathan R. > --=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 > _______________________________________________ > 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-bounces@ietf.org Wed Jun 30 05:43:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04792 for ; Wed, 30 Jun 2004 05:43:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfbcd-000280-NO for simple-archive@ietf.org; Wed, 30 Jun 2004 05:43:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfbaz-0001I3-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 05:41:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BfbYH-0000Kr-02; Wed, 30 Jun 2004 05:38:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BfbRd-00051x-J6; Wed, 30 Jun 2004 05:31:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfbIi-0000Z0-Hw; Wed, 30 Jun 2004 05:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfbCC-00083C-B7 for simple@megatron.ietf.org; Wed, 30 Jun 2004 05:16: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 FAA03764 for ; Wed, 30 Jun 2004 05:15:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfbCA-0007Ef-2x for simple@ietf.org; Wed, 30 Jun 2004 05:15:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfbBB-0006oT-00 for simple@ietf.org; Wed, 30 Jun 2004 05:14:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfbAC-000627-00 for simple@ietf.org; Wed, 30 Jun 2004 05:13:56 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i5U9Dibo002961; Wed, 30 Jun 2004 05:13:44 -0400 (EDT) Message-ID: <40E28436.5080906@dynamicsoft.com> Date: Wed, 30 Jun 2004 05:13:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP Issue 8: Etag Scope References: <2038BCC78B1AD641891A0D1AE133DBB701797CE7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CE7@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: drage@lucent.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >>> There is a requirement where key participants, for example, get >>> the privilege to modify the Dial-out list, the security >>> parameters in a conference, or add a media stream to the >>> conference. >> >> Sure. The question, however, is whether, in these cases, its >> necessary to condition these operations on the current values? > > > I was answering the question on whether there are cases that require > multiple users to modify the same piece of XML document. > > I think you are right that those cases don't need conditioning. Does that mean that you are ok with document level scopes? -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-bounces@ietf.org Wed Jun 30 05:51:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05336 for ; Wed, 30 Jun 2004 05:51:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfbkG-0005OA-54 for simple-archive@ietf.org; Wed, 30 Jun 2004 05:51:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfbjD-0004zq-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 05:50:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfbil-0004c4-00; Wed, 30 Jun 2004 05:49:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfbeB-0003UD-Mg; Wed, 30 Jun 2004 05:44:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfbUc-00020v-Dz for simple@megatron.ietf.org; Wed, 30 Jun 2004 05:35: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 FAA04384 for ; Wed, 30 Jun 2004 05:35:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfbUa-0006vo-4M for simple@ietf.org; Wed, 30 Jun 2004 05:35:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfbTZ-0006We-00 for simple@ietf.org; Wed, 30 Jun 2004 05:33:58 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BfbSc-000695-00 for simple@ietf.org; Wed, 30 Jun 2004 05:32:58 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U9Wp224628; Wed, 30 Jun 2004 12:32:51 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 12:32:33 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5U9WX71028442; Wed, 30 Jun 2004 12:32:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00SgFQRc; Wed, 30 Jun 2004 12:32:19 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5U9W2H23404; Wed, 30 Jun 2004 12:32:02 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 12:32:02 +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] XCAP Issue 8: Etag Scope Date: Wed, 30 Jun 2004 12:32:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CEA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP Issue 8: Etag Scope Thread-Index: AcRegr08asITLXlIQuKzrYubhFllPAAAlR6A To: X-OriginalArrivalTime: 30 Jun 2004 09:32:02.0080 (UTC) FILETIME=[19448A00:01C45E85] Content-Transfer-Encoding: quoted-printable Cc: drage@lucent.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 30.June.2004 12:13 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: drage@lucent.com; simple@ietf.org > Subject: Re: [Simple] XCAP Issue 8: Etag Scope >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > >>> There is a requirement where key participants, for example, get > >>> the privilege to modify the Dial-out list, the security > >>> parameters in a conference, or add a media stream to the > >>> conference. > >>=20 > >> Sure. The question, however, is whether, in these cases, its=20 > >> necessary to condition these operations on the current values? > >=20 > >=20 > > I was answering the question on whether there are cases that require > > multiple users to modify the same piece of XML document. > >=20 > > I think you are right that those cases don't need conditioning. >=20 > Does that mean that you are ok with document level scopes? Yes. /Hisham >=20 > -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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 06:02:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05819 for ; Wed, 30 Jun 2004 06:02:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfbuy-0001op-H3 for simple-archive@ietf.org; Wed, 30 Jun 2004 06:02:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfbty-0001R8-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 06:01:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfbt8-0000qY-00; Wed, 30 Jun 2004 06:00:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfbiC-00041v-UE; Wed, 30 Jun 2004 05:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfbdm-0003TV-PN for simple@megatron.ietf.org; Wed, 30 Jun 2004 05:44: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 FAA04985 for ; Wed, 30 Jun 2004 05:44:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfbdk-0002bL-Fb for simple@ietf.org; Wed, 30 Jun 2004 05:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfbcR-000260-00 for simple@ietf.org; Wed, 30 Jun 2004 05:43:08 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Bfbak-0001FI-00 for simple@ietf.org; Wed, 30 Jun 2004 05:41:22 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5U9fNAh025560 for ; Wed, 30 Jun 2004 11:41:23 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 11:41:23 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Jun 2004 11:41:23 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Cullen Jennings'" , Ben Campbell Subject: RE: [Simple] Re: MSRP: Max message size indication Date: Wed, 30 Jun 2004 11:41:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 30 Jun 2004 09:41:23.0473 (UTC) FILETIME=[67E25010:01C45E86] Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org, Paul H Kyzivat , alex.audu@alcatel.com, cboulton@ubiquity.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, >Trying to be more specific. The SDP parameter is a max size the person >receiving the SDP should send. It is the max size of the=20 >message not the chunk. The receiver SHOULD NOT send messages larger = than=20 >this. It is the size of the content not the size of the message. Yes. Regards, Christer Holmberg Ericsson Finland >=20 > Cullen, >=20 >=20 > And if it is set to 1 it means you are in character by=20 > character T.140 mode > :-) The previos line is a joke I'm not suggesting that >=20 >=20 > On 6/28/04 12:56 PM, "Ben Campbell" = wrote: >=20 > > I believe the conclusion is to allow signaling max size you wish to > > receive, but not to signal the max you intend to send. > >=20 > > Christer Holmberg (JO/LMF) wrote: > >=20 > >> Hi, > >>=20 > >> So, do we have some kind of conclusion on this? > >>=20 > >> Some people have asked for use-cases, and scenarios where=20 > this can be useful, > >> and I think a number of those have now been presented. > >>=20 > >> Regards, > >>=20 > >> Christer Holmberg > >> Ericsson Finland > >>=20 > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 15. kes=E4kuuta 2004 2:04 > >>> To: alex.audu@alcatel.com > >>> Cc: Adam Roach; 'hisham.khartabil@nokia.com'; > >>> simple@ietf.org; Christer > >>> Holmberg (JO/LMF); cboulton@ubiquity.com; Ben Campbell > >>> Subject: Re: [Simple] Re: MSRP: Max message size indication > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Alex Audu wrote: > >>>=20 > >>>> I think there is great value in end-point being able to=20 > signal the > >>>> maximum size of data it is > >>>> willing /able to accept at a time. This information could > >>>=20 > >>> be used by the=20 > >>>=20 > >>>> sender to, for example > >>>> send a less memory intensive version of say an image, > >>>=20 > >>> instead of a full > >>>=20 > >>>> blown memory hungry > >>>> version. This will allow the information to be=20 > communicated with a > >>>> decreased risk of truncation > >>>> at first try. That makes for a more efficient communication = (than > >>>> without this feature). > >>>=20 > >>> This is the most compelling argument for this feature that I > >>> have seen. > >>>=20 > >>> Paul > >>>=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 From simple-bounces@ietf.org Wed Jun 30 06:56:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08151 for ; Wed, 30 Jun 2004 06:56:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfclO-0006Ni-Ft for simple-archive@ietf.org; Wed, 30 Jun 2004 06:56:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfckT-0005yt-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 06:55:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfcjd-0005VT-00; Wed, 30 Jun 2004 06:54:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfcW6-0003By-Iw; Wed, 30 Jun 2004 06:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfcRt-0002GR-3l for simple@megatron.ietf.org; Wed, 30 Jun 2004 06:36: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 GAA06973 for ; Wed, 30 Jun 2004 06:36:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfcRq-0006Za-L2 for simple@ietf.org; Wed, 30 Jun 2004 06:36:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfcQq-0006Bc-00 for simple@ietf.org; Wed, 30 Jun 2004 06:35:13 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1BfcQ4-0005o4-00 for simple@ietf.org; Wed, 30 Jun 2004 06:34:24 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id MAA21439 for ; Wed, 30 Jun 2004 12:38:30 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma021260; Wed, 30 Jun 04 12:37:45 +0200 Received: from IVD-Message_Server by gw-server.viataal.nl with Novell_GroupWise; Wed, 30 Jun 2004 12:33:40 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 30 Jun 2004 12:33:09 +0200 From: "A vWijk" To: , , , Subject: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, toip@snowshore.com, adam@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable My comment marked with *** > >> However, I don't want to use T.140. Emulating reliability=20 > by requiring > >> multiple transmissions of every character without regard for real > >> network conditions is a horrible violation of the=20 > principles of RFC2914. >=20 > It is not T.140 you are suspicious to, it is to use the RTP=20 > packetisation text/t140 as > specified in rfc2793 ( and -bis ) that you have doubts about. >=20 > The repetitions are sent together with new characters, and=20 > therefore do not cause any > remarkable increase in load. >=20 > The unusual characteristics of this rtp packetization makes=20 > it not as horrible as you seem > to think. If it is not as horrible, then can you remind me why we are discussing = using MSRP for real time text? I am confused now since Dean gave the = reason, but you replied saying that reasoning is not entirely true. Thanks, Hisham *** The discussion about MSRP is only to play with the idea of using MSRP = for interactive text. The idea to lift with the instant messaging revolution on terminals is = apealing. But we stay with t140/rtp as described in RFC 2793( bis-07). But introducing new interactive text formats raises the danger of = incompatibilities. So that is why I am negative about just using MSRP for = interactive text. So... t140/RTP is a great solution and the redundancy usage of 2 generation= s are indeed sent by the next packet that would be sent anyway. So there = is hardly any load increase at all. And I had yesterday a call with interactive text (t140/RTP) along with = audio and video, the connection was not so good, 20% packets drop with = peaks to about 40% lost packets. Sound was bad (according the hearing = person, video was also bad with blocks in it..but the interactive text = worked just flawlessly. When disabling the interactive text, the audio and = video staryed just as crappy as they were. We talk about 2-3 kbit/sec out of 384 kbit total bandwidth used!!! THAT is = now we are talking about (yes with redundancy on!)..a tiny little ant = along the Mammoths. Just to bring it into the right perspective. :-) So, there is nothing wrong with RFC2793 interactive text. Except perhaps = that a device that does not support RTP cannot use T140/RTP. greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 07:32:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10165 for ; Wed, 30 Jun 2004 07:32:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfdK3-00059g-8F for simple-archive@ietf.org; Wed, 30 Jun 2004 07:32:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfdJB-0004mG-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 07:31:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfdIW-0004NU-00; Wed, 30 Jun 2004 07:30:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfd87-0000zp-P6; Wed, 30 Jun 2004 07:19:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfd4Q-0000aD-S4 for simple@megatron.ietf.org; Wed, 30 Jun 2004 07:16: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 HAA09155 for ; Wed, 30 Jun 2004 07:16:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfd4Q-0006RW-Dy for simple@ietf.org; Wed, 30 Jun 2004 07:16:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfd3Q-00064S-00 for simple@ietf.org; Wed, 30 Jun 2004 07:15:05 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Bfd2J-0005PA-00 for simple@ietf.org; Wed, 30 Jun 2004 07:13:55 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5UBDpPA009456 for ; Wed, 30 Jun 2004 13:13:55 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 13:13:51 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Jun 2004 13:13:51 +0200 Message-ID: <342C4681F0D4A04CA50A97D74DA8FB9A0C0AC765@esealnt875.al.sw.ericsson.se> From: "Henrik Albertsson (KI/EAB)" To: "'simple@ietf.org'" , "'Miguel.An.Garcia@nokia.com'" Date: Wed, 30 Jun 2004 13:13:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 30 Jun 2004 11:13:51.0326 (UTC) FILETIME=[52A97FE0:01C45E93] Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCAP Directory: Retrieve only lists for single AUID ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi,=20 Fist I want to say that I think that the idea behind the XCAP Directory = is good and I think this functionality is needed.=20 A question for the requirement section of the document:=20 I think that a valid requirement is that it is possible to only = retrieve the lists associated with a specified AUID(s). For example a = client interested in X-list does not want to receive Y-lists and = Z-lists.=20 This might be implicitly stated by REQ-6 but it would be good with some = clarifications from the author and perhaps update the requirements with = an explicit requirement for this. =20 Regards /Henrik =20 Henrik Albertsson=20 System Manager IMS Service Layer =20 Multimedia Solutions System Management Ericsson AB S-125 26 Stockholm=20 Sweden Tel: +46 8 719 90 73 Mobile: +46 705 19 85 39 Fax: +46 8 404 92 22 Visiting address: Kistag=E5ngen 26 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 09:34:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16399 for ; Wed, 30 Jun 2004 09:34:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BffDy-0004tb-Ox for simple-archive@ietf.org; Wed, 30 Jun 2004 09:34:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BffBk-0004Gr-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 09:31:49 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bff9R-0003K4-00; Wed, 30 Jun 2004 09:29:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bff2v-0008Th-PV; Wed, 30 Jun 2004 09:22:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfezj-0007zs-W1 for simple@megatron.ietf.org; Wed, 30 Jun 2004 09:19: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 JAA15658 for ; Wed, 30 Jun 2004 09:19:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfezj-0007Kp-Ch for simple@ietf.org; Wed, 30 Jun 2004 09:19:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfeys-0006x1-00 for simple@ietf.org; Wed, 30 Jun 2004 09:18:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bfey6-0006VF-00 for simple@ietf.org; Wed, 30 Jun 2004 09:17:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2004 09:14:45 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5UDH9Gs027877; Wed, 30 Jun 2004 09:17:10 -0400 (EDT) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJU74976; Wed, 30 Jun 2004 09:17:08 -0400 (EDT) Message-ID: <40E2BD54.1010003@cisco.com> Date: Wed, 30 Jun 2004 09:17:08 -0400 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: Ted Hardie Subject: Re: [Simple] MSRP Boundary header References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: "'Vijay Hampapur Hampapur Parthasarathy'" , seancolson@yahoo.com, "'Ben Campbell'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > At 7:48 PM -0700 6/29/04, Sean Olson wrote: > >> Why not allow both methods? >> It seems clear that there are probably two common use cases: >> >> 1) Simple, brief messages as in today's IM conversations >> 2) Larger, more complex, richer messages as forseen in 3G and other >> environments > > > Sorry to ask such a potentially silly question, but aren't the messages > in case one to be handled by SIP/SIMPLE, rather than MSRP? No. Maybe if you have a one-shot message it should be. But if you are having a conversation composed of simple brief messages then I believe the expectation is that you would be using MSRP. At least that is my expectation. One subject that has yet to be dealt with is the relationship (and possibly migration) between page mode and session mode. The fact that you ask the question you did is an indication that this isn't a solved problem. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 09:40:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16928 for ; Wed, 30 Jun 2004 09:40:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BffK6-0007Ds-0g for simple-archive@ietf.org; Wed, 30 Jun 2004 09:40:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BffIx-0006kO-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 09:39:16 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BffH0-0005qA-00; Wed, 30 Jun 2004 09:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffEE-00015I-K5; Wed, 30 Jun 2004 09:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bff3U-0008UU-2d for simple@megatron.ietf.org; Wed, 30 Jun 2004 09:23: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 JAA15819 for ; Wed, 30 Jun 2004 09:23:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bff3T-00016E-F3 for simple@ietf.org; Wed, 30 Jun 2004 09:23:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bff2R-0000h4-00 for simple@ietf.org; Wed, 30 Jun 2004 09:22:11 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Bff1S-0007kS-00 for simple@ietf.org; Wed, 30 Jun 2004 09:21:10 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5UDKNLp015936; Wed, 30 Jun 2004 08:20:23 -0500 Message-ID: <40E2BE17.9000906@dynamicsoft.com> Date: Wed, 30 Jun 2004 08:20:23 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP Boundary header References: <40E2BD54.1010003@cisco.com> In-Reply-To: <40E2BD54.1010003@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Ted Hardie , "'Vijay Hampapur Hampapur Parthasarathy'" , seancolson@yahoo.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ted Hardie wrote: > >> At 7:48 PM -0700 6/29/04, Sean Olson wrote: >> >>> Why not allow both methods? >>> It seems clear that there are probably two common use cases: >>> >>> 1) Simple, brief messages as in today's IM conversations >>> 2) Larger, more complex, richer messages as forseen in 3G and other >>> environments >> >> >> >> Sorry to ask such a potentially silly question, but aren't the messages >> in case one to be handled by SIP/SIMPLE, rather than MSRP? > > > No. Maybe if you have a one-shot message it should be. But if you are > having a conversation composed of simple brief messages then I believe > the expectation is that you would be using MSRP. > Or at one composed of a series of short, interactive messages. (Which is probably what Paul meant to say. > At least that is my expectation. One subject that has yet to be dealt > with is the relationship (and possibly migration) between page mode and > session mode. The fact that you ask the question you did is an > indication that this isn't a solved problem. > This is true. We have had discussions indicating that we need to say something about when to use each, and how to transition between them. I personally think that sort of thing belong in the SIMPLE architecture draft effort, which we have not been putting much effort into of late. > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 10:05:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18500 for ; Wed, 30 Jun 2004 10:05:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bffi7-0001dG-98 for simple-archive@ietf.org; Wed, 30 Jun 2004 10:05:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bffh1-0000qu-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 10:04:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfffY-0000FW-00; Wed, 30 Jun 2004 10:02:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffTK-0003d6-Nt; Wed, 30 Jun 2004 09:49:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffKy-0002Gy-MR for simple@megatron.ietf.org; Wed, 30 Jun 2004 09:41: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 JAA17029 for ; Wed, 30 Jun 2004 09:41:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BffKy-0007dD-1P for simple@ietf.org; Wed, 30 Jun 2004 09:41:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BffJt-0006w0-00 for simple@ietf.org; Wed, 30 Jun 2004 09:40: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 1BffIQ-0006Jr-00 for simple@ietf.org; Wed, 30 Jun 2004 09:38:42 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5UDblLp016043; Wed, 30 Jun 2004 08:37:47 -0500 Message-ID: <40E2C22C.8050800@dynamicsoft.com> Date: Wed, 30 Jun 2004 08:37:48 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Re: MSRP: Max message size indication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i5UDblLp016043 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" , Paul H Kyzivat , alex.audu@alcatel.com, cboulton@ubiquity.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cullen Jennings wrote: > Trying to be more specific. The SDP parameter is a max size the person > receiving the SDP should send. It is the max size of the message not th= e > chunk. The receiver SHOULD NOT send messages larger than this. It is th= e > size of the content not the size of the message. Agreed. >=20 > Cullen, >=20 >=20 > And if it is set to 1 it means you are in character by character T.140 = mode > :-) The previos line is a joke I'm not suggesting that >=20 >=20 I don't want to solve that problem just yet. _But_, do you really=20 consider a real time text usage of MSRP by sending one character per=20 chunk to be acceptable? Talk about a bandwidth explosion. I think we=20 will need something more complicated for that to work. > On 6/28/04 12:56 PM, "Ben Campbell" wrote: >=20 >=20 >>I believe the conclusion is to allow signaling max size you wish to >>receive, but not to signal the max you intend to send. >> >>Christer Holmberg (JO/LMF) wrote: >> >> >>>Hi, >>> >>>So, do we have some kind of conclusion on this? >>> >>>Some people have asked for use-cases, and scenarios where this can be = useful, >>>and I think a number of those have now been presented. >>> >>>Regards, >>> >>>Christer Holmberg >>>Ericsson Finland >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: 15. kes=E4kuuta 2004 2:04 >>>>To: alex.audu@alcatel.com >>>>Cc: Adam Roach; 'hisham.khartabil@nokia.com'; >>>>simple@ietf.org; Christer >>>>Holmberg (JO/LMF); cboulton@ubiquity.com; Ben Campbell >>>>Subject: Re: [Simple] Re: MSRP: Max message size indication >>>> >>>> >>>> >>>> >>>>Alex Audu wrote: >>>> >>>> >>>>>I think there is great value in end-point being able to signal the >>>>>maximum size of data it is >>>>>willing /able to accept at a time. This information could >>>> >>>>be used by the=20 >>>> >>>> >>>>>sender to, for example >>>>>send a less memory intensive version of say an image, >>>> >>>>instead of a full >>>> >>>> >>>>>blown memory hungry >>>>>version. This will allow the information to be communicated with a >>>>>decreased risk of truncation >>>>>at first try. That makes for a more efficient communication (than >>>>>without this feature). >>>> >>>>This is the most compelling argument for this feature that I >>>>have seen. >>>> >>>>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-bounces@ietf.org Wed Jun 30 10:05:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18600 for ; Wed, 30 Jun 2004 10:05:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BffiS-0001g9-7R for simple-archive@ietf.org; Wed, 30 Jun 2004 10:05:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BffhX-0001FF-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 10:04:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bffga-0000Tp-00; Wed, 30 Jun 2004 10:03:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffYP-0004UG-6M; Wed, 30 Jun 2004 09:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffNk-0002SD-57 for simple@megatron.ietf.org; Wed, 30 Jun 2004 09: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 JAA17115 for ; Wed, 30 Jun 2004 09:44:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BffNj-000106-ET for simple@ietf.org; Wed, 30 Jun 2004 09:44:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BffMk-0000c5-00 for simple@ietf.org; Wed, 30 Jun 2004 09:43:10 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BffLf-0007ec-00 for simple@ietf.org; Wed, 30 Jun 2004 09:42:03 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5UDfBLp016050; Wed, 30 Jun 2004 08:41:11 -0500 Message-ID: <40E2C2F8.8040907@dynamicsoft.com> Date: Wed, 30 Jun 2004 08:41:12 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] MSRP: Surpression of duplicates References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 6/29/04 12:41 AM, "hisham.khartabil@nokia.com" > wrote: > > >> >>>-----Original Message----- >>>From: simple-bounces@ietf.org >>>[mailto:simple-bounces@ietf.org]On Behalf >>>Of ext Ben Campbell >>>Sent: 28.June.2004 23:36 >>>To: Simple WG >>>Subject: [Simple] MSRP: Surpression of duplicates >>> >>> >>>The working group has gone round and round on whether (and how) we >>>handle worry about the surpression of duplicate messages, in >>>situations >>>where a failure occurs, and the sender chooses to re-send >>>content on a >>>new session. >>> >>>Since we have introduced the concept of a MessageID, this >>>becomes fairly >>>easy to accomplish. If we specify the MessageID to be >>>globally unique, >>>or even just very likely to re-occur in a relatively short >>>time period, >>>then the receive can simply watch for duplicate messageIDs. The >>>receiver's action upon receiving a duplicate would be entirely up to >>>local policy (although simply displaying the duplicate to the user >>>without any warning of duplication would be a bad choice.) >>> >>>This approach only works for detecting whole-content >>>duplication, rather >>>than chunk duplication. We recommend that chunks of a given >>>message not >>>be spread across more than one session. >> >>I don't like this recommendation. If I'm sending you a 5GB file in chunks and >>the session breaks, then I would like to continue where I left off. But I >>guess it doesn't necessarily have to be the same message ID. > > > I got lost on this - I think I agree with Hisham - I think the mechanims > does work for chunk duplicate - you find a message using the messageId and > if you already have data for the range of data in the chunk, you can ignore > the part that is an overlap. Perhaps that is what you say in the next > paragraph Yes. I meant to say that, the message ID plus the byterange information is sufficient to detect chunk duplication or overlap, so we don't need some special chunk ID. I believe Hisham was objecting to the recommendation not to spread chunks of the same message accross sessions. I will back away from that a bit and say you shouldn't do it under normal conditions, but it may be acceptable for recovering from a failed session. (Hisham, would that make you happier?) > > > >>>Within any given session, the >>>chunking mechanism already provides a way to notice >>>duplication--you can >>>watch for byte-range overlaps. >>> >>>If there are no subtantive objections to the approach, the next draft >>>version will describe the details. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 11:01:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22493 for ; Wed, 30 Jun 2004 11:01:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfgae-0000c2-QL for simple-archive@ietf.org; Wed, 30 Jun 2004 11:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfgZX-0000Cl-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 11:00:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfgZ1-0007a5-00; Wed, 30 Jun 2004 10:59:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfgTQ-0001oC-Nw; Wed, 30 Jun 2004 10:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfgQF-0001P2-2v for simple@megatron.ietf.org; Wed, 30 Jun 2004 10:50: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 KAA22011 for ; Wed, 30 Jun 2004 10:50:48 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfgQE-0003zL-EO for simple@ietf.org; Wed, 30 Jun 2004 10:50:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfgPO-0003Xp-00 for simple@ietf.org; Wed, 30 Jun 2004 10:49:59 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BfgNZ-0002df-00 for simple@ietf.org; Wed, 30 Jun 2004 10:48:05 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UElvN15565; Wed, 30 Jun 2004 17:47:57 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 17:47:56 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5UEluDo010050; Wed, 30 Jun 2004 17:47:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00L1ZWfH; Wed, 30 Jun 2004 17:47:54 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UElqH16435; Wed, 30 Jun 2004 17:47:52 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 17:47:50 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 17:47:50 +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: Surpression of duplicates Date: Wed, 30 Jun 2004 17:47:49 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797CED@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Surpression of duplicates Thread-Index: AcReqCr+voocBM82TWOyFJdBHjZ/QwACPUjQ To: , X-OriginalArrivalTime: 30 Jun 2004 14:47:50.0474 (UTC) FILETIME=[376402A0:01C45EB1] Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 30.June.2004 16:41 > To: Cullen Jennings > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] MSRP: Surpression of duplicates >=20 >=20 >=20 >=20 > Cullen Jennings wrote: >=20 > > On 6/29/04 12:41 AM, "hisham.khartabil@nokia.com" > > wrote: > >=20 > >=20 > >> > >>>-----Original Message----- > >>>From: simple-bounces@ietf.org > >>>[mailto:simple-bounces@ietf.org]On Behalf > >>>Of ext Ben Campbell > >>>Sent: 28.June.2004 23:36 > >>>To: Simple WG > >>>Subject: [Simple] MSRP: Surpression of duplicates > >>> > >>> > >>>The working group has gone round and round on whether (and how) we > >>>handle worry about the surpression of duplicate messages, in > >>>situations=20 > >>>where a failure occurs, and the sender chooses to re-send > >>>content on a=20 > >>>new session. > >>> > >>>Since we have introduced the concept of a MessageID, this > >>>becomes fairly=20 > >>>easy to accomplish. If we specify the MessageID to be > >>>globally unique, > >>>or even just very likely to re-occur in a relatively short > >>>time period,=20 > >>>then the receive can simply watch for duplicate messageIDs. The > >>>receiver's action upon receiving a duplicate would be=20 > entirely up to > >>>local policy (although simply displaying the duplicate to the user > >>>without any warning of duplication would be a bad choice.) > >>> > >>>This approach only works for detecting whole-content > >>>duplication, rather > >>>than chunk duplication. We recommend that chunks of a given > >>>message not=20 > >>>be spread across more than one session. > >> > >>I don't like this recommendation. If I'm sending you a 5GB=20 > file in chunks and > >>the session breaks, then I would like to continue where I=20 > left off. But I > >>guess it doesn't necessarily have to be the same message ID. > >=20 > >=20 > > I got lost on this - I think I agree with Hisham - I think=20 > the mechanims > > does work for chunk duplicate - you find a message using=20 > the messageId and > > if you already have data for the range of data in the=20 > chunk, you can ignore > > the part that is an overlap. Perhaps that is what you say=20 > in the next > > paragraph >=20 > Yes. I meant to say that, the message ID plus the byterange=20 > information=20 > is sufficient to detect chunk duplication or overlap, so we=20 > don't need=20 > some special chunk ID. >=20 > I believe Hisham was objecting to the recommendation not to spread=20 > chunks of the same message accross sessions. I will back away=20 > from that=20 > a bit and say you shouldn't do it under normal conditions,=20 > but it may be=20 > acceptable for recovering from a failed session. >=20 > (Hisham, would that make you happier?) Yes. I only wanted it for failed sessions. Thanks, Hisham >=20 >=20 > >=20 > >=20 > >=20 > >>>Within any given session, the > >>>chunking mechanism already provides a way to notice > >>>duplication--you can > >>>watch for byte-range overlaps. > >>> > >>>If there are no subtantive objections to the approach, the=20 > next draft > >>>version will describe the details. >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 11:17:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23470 for ; Wed, 30 Jun 2004 11:17:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfgq1-0007JU-KJ for simple-archive@ietf.org; Wed, 30 Jun 2004 11:17:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfgp6-0006u5-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 11:16:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfgoH-00066E-00; Wed, 30 Jun 2004 11:15:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfglA-00046j-S8; Wed, 30 Jun 2004 11:12:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfgiC-0003Wi-1h for simple@megatron.ietf.org; Wed, 30 Jun 2004 11:09: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 LAA23029 for ; Wed, 30 Jun 2004 11:09:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfgiB-0003yM-9K for simple@ietf.org; Wed, 30 Jun 2004 11:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfghI-0003YT-00 for simple@ietf.org; Wed, 30 Jun 2004 11:08:28 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfggH-0002hu-00 for simple@ietf.org; Wed, 30 Jun 2004 11:07:25 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5UF6sLp016477; Wed, 30 Jun 2004 10:06:54 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1088608002.2201.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 30 Jun 2004 10:06:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Hisham Khartabil Subject: [Simple] WGLC: Event Filtering X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is a SIMPLE working group last call for the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-01.txt Please provide comments to the list or chairs by July 16. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 12:38:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27848 for ; Wed, 30 Jun 2004 12:38:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfi6G-0000As-NT for simple-archive@ietf.org; Wed, 30 Jun 2004 12:38:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfi5I-0007Ys-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 12:37:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfi4D-0006nQ-00; Wed, 30 Jun 2004 12:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfhuq-0004qh-BC; Wed, 30 Jun 2004 12:26:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfhi7-0002Vn-IL for simple@megatron.ietf.org; Wed, 30 Jun 2004 12:13:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26773 for ; Wed, 30 Jun 2004 12:13:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfhi6-0005eW-HF for simple@ietf.org; Wed, 30 Jun 2004 12:13:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfhh5-0005Eg-00 for simple@ietf.org; Wed, 30 Jun 2004 12:12:20 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Bfhg1-0004hj-00 for simple@ietf.org; Wed, 30 Jun 2004 12:11:14 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UGBB604204; Wed, 30 Jun 2004 19:11:11 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 19:11:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5UGB01a017847; Wed, 30 Jun 2004 19:11:00 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00CEYKej; Wed, 30 Jun 2004 19:11:00 EEST Received: from nokia.com (esnira-pool401599.nokia.com [10.162.15.99]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UGAkH05057; Wed, 30 Jun 2004 19:10:48 +0300 (EET DST) Message-ID: <40E2E5FF.7080407@nokia.com> Date: Wed, 30 Jun 2004 19:10:39 +0300 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] XCAP Issue 9: Etags mostly useless for insert References: <40DAB1D5.10802@dynamicsoft.com> In-Reply-To: <40DAB1D5.10802@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: > [resend] > > While working through the text on etags, I ran into an interesting > issue. Its not clear its a problem, but its something that needs to be > documented if we decide its not. > > The issue is that, when you do a conditional PUT (that is, a PUT with an > If-Match containing an etag), the conditioning is based on the etag for > *that* resource. There is no way to say, "perform this PUT on resource > X, but only if the etag for resource Y has not changed". Why is this an > issue? Well, let me give a concrete example. > > Lets say I have a basic buddy list that looks like this: > > > xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > subscribeable="true"> > > Bill Doe > > subscribeable="true"> > > Joe Smith > > > Nancy Gross > > http://www.example.org/xcap/resource-lists/users/a/foo > > > > > > and lets consider the simplest etag scope (this issue doesnt matter what > we decide to do for etag scopes per issue 8), where every resource in > the document has the same value for its etag. Its important to > understand that etags are associated with a resource. Even if we decide > that all resources will share the same value for their etags, they still > each have their own etags. > > Lets say that the current etag for this document (and all resources > within it) is 2. I decide to insert a new entry, and so I do this: > > PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ > resource-lists/list[@name="friends"]/entry[@name="Mikko"] > If-Match: 1 > > > > > > You would think that this insertion would be done if the document had > not been modified (i.e., its etag was still 1), but that is NOT what > this request will do. The conditioning here means that the PUT is only > done if the etag for the resource in the request URI has an etag of 1. > Of course, the resource in the request URI doesnt yet exist (thats why > its an insert), so this request will be rejected with a 412. > > Basically, there is no way to do an insert, and say, "don't do this > insertion if the document hasn't changed since etag 1". You can say, > "don't do this insert if this resource exists", by using an > If-Not-Match: *. So, you can at least guarantee that what you think is > an insertion, really is an insertion. > > So, the question is, is this a problem? I don't think so. Or, more > concretely, I couldn't think of a use case where this was a problem. > If-None-Match: * will certainly help (and make the request much safer) if you want to insert with r-uri like PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ resource-lists/list[@name="friends"]/entry[5] where this new entry is the last one in the "friends" list. Anyway, it would have been also much easier both for the client and the server if it had been possible to use the only valid context for ETag in this case i.e. the parent node of the inserted new node. > Consider the following example. Once again, we have the document above, > and client A has a copy of it locally, in memory, with etag 1. Client 2 > makes a change, and the change it makes is to delete the close-friends > list. Client 1 then tries to do an insert into this list, and so it does: > > PUT http://server.com/xcap-root/resource-lists/users/bob/mylist/~/ > resource-lists/list[@name="friends"]/ > list[@name="close-friends"]/entry[@name="Paul"] > > > > Fortunately, this will request will fail with a 409, since the parent of > entry[@name="Paul"] doesnt exist anymore. The client could then refetch > the document and figure out why this error happened. > > So, no problem here. > > COnsider a different case. Client 1 has this list locally. Client 2 > changes the name of "close-friends" to "really-close-friends". Same > thing happens as the previous example. > > In yet another case, client 2 changes the subscribeable flag for > close-friends from true to false. In this case, the insert done by > client 1 will succeed. THe problem is that the client no longer has a > correct copy of the document cached. If this is a problem, the client > can refetch the document. > > I'll also note that, if you use the xcap package, this problem pretty > much goes away. > > As far as I can tell, we have three choices about what to do about this > "problem": > > 1. document the situation so its clear what etags do and don't do for you > I'll vote this 1. one too. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 12:42:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28112 for ; Wed, 30 Jun 2004 12:42:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfiAM-0001pI-J9 for simple-archive@ietf.org; Wed, 30 Jun 2004 12:42:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfi9J-0001Pe-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 12:41:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfi8K-0000cf-00; Wed, 30 Jun 2004 12:40:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfi2R-0005dQ-IC; Wed, 30 Jun 2004 12:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfhtk-0004kb-GE for simple@megatron.ietf.org; Wed, 30 Jun 2004 12:25: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 MAA27207 for ; Wed, 30 Jun 2004 12:25:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfhtj-0002g0-Ck for simple@ietf.org; Wed, 30 Jun 2004 12:25:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfhso-0002HR-00 for simple@ietf.org; Wed, 30 Jun 2004 12:24:29 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Bfhry-0001VK-00 for simple@ietf.org; Wed, 30 Jun 2004 12:23:34 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5UGMgN23746; Wed, 30 Jun 2004 12:22:42 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jun 2004 12:22:41 -0400 Message-ID: From: "Mary Barnes" To: "'hisham.khartabil@nokia.com'" , gunnar.hellstrom@omnitor.se, dean.willis@softarmor.com, bcampbell@dynamicsoft.com Subject: RE: [Simple] Using MSRP for real time text conversation Date: Wed, 30 Jun 2004 12:22:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: stf267@etsi.org, adam@dynamicsoft.com, toip@snowshore.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0973883499==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0973883499== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45EBE.6DF7FA1A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45EBE.6DF7FA1A Content-Type: text/plain Hisham, I totally understand not wanting to delay MSRP. However, it seems to me that real time text is a really good basic use case for MSRP. I realize it may not be specifically detailed in the charter, but there had been a general agreement way back in SIPPING in London to make sure that requirements for hearing impaired were built into the base specs, rather than bolted on after the fact. And, it's clearly part of the SIPPING charter, that perhaps should have been explicitly propagated to the SIMPLE WG charter: " 2. Messaging-like applications of SIP - - support for hearing-/speech-impaired calling " Regards, Mary. -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Wednesday, June 30, 2004 3:02 AM To: gunnar.hellstrom@omnitor.se; dean.willis@softarmor.com; bcampbell@dynamicsoft.com Cc: stf267@etsi.org; toip@snowshore.com; adam@dynamicsoft.com; simple@ietf.org Subject: RE: [Simple] Using MSRP for real time text conversation I am not willing to delay the completion of MSRP for this. However, I am not going to kill the idea of using MSRP for real-time text. I believe it is worth considering, but after the base MSRP spec has passed. It sounds reasonable to have real-time text as an implementation choice for clients where users can flick a switch to turn it on or off. Having a 500ms buffer seems to aid in solving the character-by-character issues. This requires 1 of 2 things: specify the behaviour in a way that enables one side (the sender) to support real-time text while the other can be oblivious of that. Or, specify an SDP negotiation for it. Again, I am against the idea of having the solution for this appear in the current MSRP spec as it will cause delays. We have external standardisation bodies awaiting this and it so close to completion now I would hate to delay it any further. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Gunnar Hellstrom > Sent: 29.June.2004 22:58 > To: Dean Willis; Ben Campbell > Cc: STF267; Adam Roach; toip@snowshore.com; simple@ietf.org > Subject: RE: [Simple] Using MSRP for real time text conversation > > > Thanks for good summaries and questions. > Comments inline, > > > >Re-adding my comments to this branch of the thread: > > > >Dean Willis wrote: > > > >> > >> > >> Adam Roach wrote: > >> > >>> Gunnar: > >>> > >>> I'm very confused. Why do you want to use MSRP for T.140 text? You > >>> don't *need* MSRP to have T.140 conversations. You just carry them > >>> like any other real-time streams -- isn't that the point > of RFC 2793? > >>> > >> > >> Darn these cross-list discussions. You and Hisham seem to > have missed > >> the first forty messages in this thread, and reacted with > justifiable > >> surprise. > >> > >> Recap, for those who missed the first season of our serial drama: > >> > >> Gunnar does NOT "want" to use MSRP -- he proposed using > T.140 exactly as > >> you discussed it above. He also wants real-time text in > every phone and > >> messaging device produced, for 100% availability, a goal > that I find > >> agreeable. > >> > >> However, I don't want to use T.140. Emulating reliability > by requiring > >> multiple transmissions of every character without regard for real > >> network conditions is a horrible violation of the > principles of RFC2914. > > It is not T.140 you are suspicious to, it is to use the RTP > packetisation text/t140 as > specified in rfc2793 ( and -bis ) that you have doubts about. > > The repetitions are sent together with new characters, and > therefore do not cause any > remarkable increase in load. > > The unusual characteristics of this rtp packetization makes > it not as horrible as you seem > to think. > > It is not a true character-by-character transmission. All > characters typed during a > buffering interval are transmitted together. The default > buffering time is 300 ms. If no > data is available for transmission, no packet is sent. > > User spend often more time thinking and reading than they > spend typing. So, studying max > values does not give you a good view of the real ( low ) load. > > The additional words about actions in case of congestion > should be effective. RTCP info > can be the base for increasing buffering time. > > >> > >> So, I raised the question: Could we use a reliable and > 2914-compliant > >> protocol like MSRP to meet the needs of real-time text? We are now > >> discussing this possibility, using MSRP as the baseline. > >> > >> Open questions: > >> > >> 1) Would the user experience be acceptable? > With 300 ms between transmissions if there is data, I would > expect MSRP to behave just as > well as RTP text/t140, assuming that it gets through NAT and > firewalls. > > We saw that the bandwidth seems to be 3 times higher for > MSRP. If we compensate by > increasing buffering time we reach 1 second buffering time, > and that will be regarded too > slow and chunky. 500 ms is the limit. > > >> > >> 2) What is the bandwidth required, relative to T.140? > > > >If you send one char per message, absurdly huge. If you use > some of the > >streaming features of MSRP, this might could be somewhat > mitigated. But > >this would be an extremely constrained and mutant usage of > MSRP as it is > >currently described. > With maximum allowable 500 ms for MSRP it will be 4 kbit/s. > With 300 ms buffering it will > be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a > mobile situation. Otherwise > it is probably OK. We are dealing with calls where it will be > in many cases favourable to > use video and audio as well. > > > >> > >> 3) How much change would this imply for MSRP? > >> > > > >I am assuming the 1 char per message approach is not even on > the table. > >If you use a stream approach, you will need loads of new > rules about how > >to do this, and how to signal you want to do it. > Look at 500 ms buffering instead. > Would you dare to recommend it then? > > > > > >> 4) How will this affect the widepsread availability of > real-time text? > >> Cullen has proposed that if this is simple as a check-box > in the GUI of > >> every MSRP client, then EVERYBODY has eal-time text capability. > >> > > > >I have no opinion on this. The jury is still out on the wide-spread > >acceptance of MSRP. > > I definitely hope that simple and MSRP gets widespread. The > current fragmentation in the I > M world is a severely hampering factor for its message-wise > use. Impossible to procure for > official use, impossible to use for public services. I wish > you all luck with a > standardised protocol to replace the current situation! > > But for its influence on the real time variant, I also want > to listen to the word from the > jury... > > > >> 5) What are the pros and cons of the various approaches > with respect to > >> firewalls and NATs? Clearly TCP has some advantages, and MSRP has > >> relays, but TURN and STUN give us some existing > infrastructure for T.140. > > There are also true SIP aware NAT-routers and firewalls that > handle SIP and RTP well. I do > not know how well they handle MSRP. > >> > >> 6) is there a sufficient perception of value in the > community to justify > >> adding this sort of function to MSRP, or would yet another > protocol be > >> required? > > > >Well, adding this to the MSRP base spec would be long and > painful. I am > >in principle opposed to adding any significant new > requirements to MSRP, > >as it would put at serious risk of never completing it. > Three small things need to be done: > a. Optional real time transmission in 500 ms buffers. > b. MIME declaration of the transmission in a new text/t140p > format that is just the plain > UTF-8 coded T.140 transmission. > c. A request on the receiver to add received text for display > in one window per > transmitting party. > > > > > > >I also don't think that real-time text is in scope, or in > charter, for > >SIMPLE. > > > >Now, if we, or someone else, decide(s) that it makes sense to extend > >MSRP to allow this, I am not strongly opposed, as long as it does not > >disrupt work on the base spec. (I am not by that statement indicating > >that I do thing it makes sense.) > > > Same here, we have to judge the possible outcome of question > 4 above, and balance it > against the influence on already started activities to > specify text/t140 as the way to do > text conversation, emergency etc. > > Gunnar > >> > >> -- > >> Dean > >> > >> _______________________________________________ > >> 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 ------_=_NextPart_001_01C45EBE.6DF7FA1A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Simple] Using MSRP for real time text conversation

Hisham,

I totally understand not wanting to delay MSRP.  = However, it seems to me that real time text is a really good basic use = case for MSRP.  I realize it may not be specifically detailed in = the charter, but there had been a general agreement way back in SIPPING = in London to make sure that requirements for hearing impaired were = built into the base specs, rather than bolted on after the fact.  = And, it's clearly part of the SIPPING charter, that perhaps should have = been explicitly propagated to the SIMPLE WG charter:

" 2. Messaging-like applications of SIP -

  - support for hearing-/speech-impaired = calling  "

Regards,
Mary.

-----Original Message-----
From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia= .com]
Sent: Wednesday, June 30, 2004 3:02 AM
To: gunnar.hellstrom@omnitor.se; = dean.willis@softarmor.com; bcampbell@dynamicsoft.com
Cc: stf267@etsi.org; toip@snowshore.com; = adam@dynamicsoft.com; simple@ietf.org
Subject: RE: [Simple] Using MSRP for real time text = conversation


I am not willing to delay the completion of MSRP for = this. However, I am not going to kill the idea of using MSRP for = real-time text. I believe it is worth considering, but after the base = MSRP spec has passed.

It sounds reasonable to have real-time text as an = implementation choice for clients where users can flick a switch to = turn it on or off. Having a 500ms buffer seems to aid in solving the = character-by-character issues.

This requires 1 of 2 things: specify the behaviour in = a way that enables one side (the sender) to support real-time text = while the other can be oblivious of that. Or, specify an SDP = negotiation for it.

Again, I am against the idea of having the solution = for this appear in the current MSRP spec as it will cause delays. We = have external standardisation bodies awaiting this and it so close to = completion now I would hate to delay it any further.

Regards,
Hisham

> -----Original Message-----
> From: simple-bounces@ietf.org
> [mailto:simple-bounces@ietf.org]On Behalf
> Of ext Gunnar Hellstrom
> Sent: 29.June.2004 22:58
> To: Dean Willis; Ben Campbell
> Cc: STF267; Adam Roach; toip@snowshore.com; = simple@ietf.org
> Subject: RE: [Simple] Using MSRP for real time = text conversation
>
>
> Thanks for good summaries and questions.
> Comments inline,
>
>
> >Re-adding my comments to this branch of the = thread:
> >
> >Dean Willis wrote:
> >
> >>
> >>
> >> Adam Roach wrote:
> >>
> >>> Gunnar:
> >>>
> >>> I'm very confused. Why do you want = to use MSRP for T.140 text? You
> >>> don't *need* MSRP to have T.140 = conversations. You just carry them
> >>> like any other real-time streams = -- isn't that the point
> of RFC 2793?
> >>>
> >>
> >> Darn these cross-list discussions. You = and Hisham seem to
> have missed
> >> the first forty messages in this = thread, and reacted with
> justifiable
> >> surprise.
> >>
> >> Recap, for those who missed the first = season of our serial drama:
> >>
> >> Gunnar does NOT "want" to = use MSRP -- he proposed using
> T.140 exactly as
> >> you discussed it above. He also wants = real-time text in
> every phone and
> >> messaging device produced, for 100% = availability, a goal
> that I find
> >> agreeable.
> >>
> >> However, I don't want to use T.140. = Emulating reliability
> by requiring
> >> multiple transmissions of every = character without regard for real
> >> network conditions is a horrible = violation of the
> principles of RFC2914.
>
> It is not T.140 you are suspicious to, it is to = use the RTP
> packetisation text/t140 as
> specified in rfc2793 ( and -bis ) that you have = doubts about.
>
> The repetitions are sent together with new = characters, and
> therefore do not cause any
> remarkable increase in load.
>
> The unusual characteristics of this rtp = packetization makes
> it not as horrible as you seem
> to think.
>
> It is not a true character-by-character = transmission. All
> characters typed during a
> buffering interval are transmitted together. = The default
> buffering time is 300 ms. If no
> data is available for transmission, no packet = is sent.
>
> User spend often more time thinking and reading = than they
> spend typing. So, studying max
> values does not give you a good view of the = real ( low ) load.
>
> The additional words about actions in case of = congestion
> should be effective. RTCP info
> can be the base for increasing buffering = time.
>
> >>
> >> So, I raised the question: Could we = use a reliable and
> 2914-compliant
> >> protocol like MSRP to meet the needs = of real-time text? We are now
> >> discussing this possibility, using = MSRP as the baseline.
> >>
> >> Open questions:
> >>
> >> 1) Would the user experience be = acceptable?
> With 300 ms between transmissions if there is = data, I would
> expect MSRP to behave just as
> well as RTP text/t140, assuming that it gets = through NAT and
> firewalls.
>
> We saw that the bandwidth seems to be 3 times = higher for
> MSRP. If we compensate by
> increasing buffering time we reach 1 second = buffering time,
> and that will be regarded too
> slow and chunky. 500 ms is the limit.
>
> >>
> >> 2) What is the bandwidth required, = relative to T.140?
> >
> >If you send one char per message, absurdly = huge. If you use
> some of the
> >streaming features of MSRP, this might = could be somewhat
> mitigated. But
> >this would be an extremely constrained and = mutant usage of
> MSRP as it is
> >currently described.
> With maximum allowable 500 ms for MSRP it will = be 4 kbit/s.
> With 300 ms buffering it will
> be 2 kbit/s for text/t140. 4 kbit/s would not = be popular in a
> mobile situation. Otherwise
> it is probably OK. We are dealing with calls = where it will be
> in many cases favourable to
> use video and audio as well.
> >
> >>
> >> 3) How much change would this imply = for MSRP?
> >>
> >
> >I am assuming the 1 char per message = approach is not even on
> the table.
> >If you use a stream approach, you will need = loads of new
> rules about how
> >to do this, and how to signal you want to = do it.
> Look at 500 ms buffering instead.
> Would you dare to recommend it then?
>
>
> >
> >> 4) How will this affect the widepsread = availability of
> real-time text?
> >> Cullen has proposed that if this is = simple as a check-box
> in the GUI of
> >> every MSRP client, then EVERYBODY has = eal-time text capability.
> >>
> >
> >I have no opinion on this. The jury is = still out on the wide-spread
> >acceptance of MSRP.
>
> I definitely hope that simple and MSRP gets = widespread. The
> current fragmentation in the I
> M world is a severely hampering factor for its = message-wise
> use. Impossible to procure for
> official use, impossible to use for public = services. I wish
> you all luck with a
> standardised protocol to replace the current = situation!
>
> But for its influence on the real time variant, = I also want
> to listen to the word from the
> jury...
> >
> >> 5) What are the pros and cons of the = various approaches
> with respect to
> >> firewalls and NATs? Clearly TCP has = some advantages, and MSRP has
> >> relays, but TURN and STUN give us some = existing
> infrastructure for T.140.
>
> There are also true SIP aware NAT-routers and = firewalls that
> handle SIP and RTP well. I do
> not know how well they handle MSRP.
> >>
> >> 6) is there a sufficient perception of = value in the
> community to justify
> >> adding this sort of function to MSRP, = or would yet another
> protocol be
> >> required?
> >
> >Well, adding this to the MSRP base spec = would be long and
> painful. I am
> >in principle opposed to adding any = significant new
> requirements to MSRP,
> >as it would put at serious risk of never = completing it.
> Three small things need to be done:
> a. Optional real time transmission in 500 ms = buffers.
> b. MIME declaration of the transmission in a = new text/t140p
> format that is just the plain
> UTF-8 coded T.140 transmission.
> c. A request on the receiver to add received = text for display
> in one window per
> transmitting party.
>
>
>
> >
> >I also don't think that real-time text is = in scope, or in
> charter, for
> >SIMPLE.
> >
> >Now, if we, or someone else, decide(s) that = it makes sense to extend
> >MSRP to allow this, I am not strongly = opposed, as long as it does not
> >disrupt work on the base spec. (I am not by = that statement indicating
> >that I do thing it makes sense.)
> >
> Same here, we have to judge the possible = outcome of question
> 4 above, and balance it
> against the influence on already started = activities to
> specify text/t140 as the way to do
> text conversation, emergency etc.
>
> Gunnar
> >>
> >> --
> >> Dean
> >>
> >> = _______________________________________________
> >> 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

------_=_NextPart_001_01C45EBE.6DF7FA1A-- --===============0973883499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0973883499==-- From simple-bounces@ietf.org Wed Jun 30 13:09:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29575 for ; Wed, 30 Jun 2004 13:09:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfiaJ-0004xU-L9 for simple-archive@ietf.org; Wed, 30 Jun 2004 13:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfiZH-0004YY-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 13:08:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfiY9-0003nN-00; Wed, 30 Jun 2004 13:07:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfiVA-0001oC-R3; Wed, 30 Jun 2004 13:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfiQh-00012M-D9 for simple@megatron.ietf.org; Wed, 30 Jun 2004 12:59: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 MAA29003 for ; Wed, 30 Jun 2004 12:59:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfiQg-0000tV-7D for simple@ietf.org; Wed, 30 Jun 2004 12:59:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfiPm-0000VT-00 for simple@ietf.org; Wed, 30 Jun 2004 12:58:30 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BfiOw-0007WC-00 for simple@ietf.org; Wed, 30 Jun 2004 12:57:38 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i5UGtjRn005151; Wed, 30 Jun 2004 11:55:45 -0500 (CDT) Message-ID: <40E2F090.65B4A83D@alcatel.com> Date: Wed, 30 Jun 2004 11:55:44 -0500 From: Alex Audu X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Re: MSRP: Max message size indication References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds953.usa.alcatel.com id i5UGtjRn005151 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org, "Christer Holmberg \(JO/LMF\)" , Paul H Kyzivat , cboulton@ubiquity.com, Ben Campbell X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alex.audu@alcatel.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Cullen, Yeap,..this will do. Thanks, Alex. Cullen Jennings wrote: > Trying to be more specific. The SDP parameter is a max size the person > receiving the SDP should send. It is the max size of the message not th= e > chunk. The receiver SHOULD NOT send messages larger than this. It is th= e > size of the content not the size of the message. > > Cullen, > > And if it is set to 1 it means you are in character by character T.140 = mode > :-) The previos line is a joke I'm not suggesting that > > On 6/28/04 12:56 PM, "Ben Campbell" wrote: > > > I believe the conclusion is to allow signaling max size you wish to > > receive, but not to signal the max you intend to send. > > > > Christer Holmberg (JO/LMF) wrote: > > > >> Hi, > >> > >> So, do we have some kind of conclusion on this? > >> > >> Some people have asked for use-cases, and scenarios where this can b= e useful, > >> and I think a number of those have now been presented. > >> > >> Regards, > >> > >> Christer Holmberg > >> Ericsson Finland > >> > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 15. kes=E4kuuta 2004 2:04 > >>> To: alex.audu@alcatel.com > >>> Cc: Adam Roach; 'hisham.khartabil@nokia.com'; > >>> simple@ietf.org; Christer > >>> Holmberg (JO/LMF); cboulton@ubiquity.com; Ben Campbell > >>> Subject: Re: [Simple] Re: MSRP: Max message size indication > >>> > >>> > >>> > >>> > >>> Alex Audu wrote: > >>> > >>>> I think there is great value in end-point being able to signal th= e > >>>> maximum size of data it is > >>>> willing /able to accept at a time. This information could > >>> > >>> be used by the > >>> > >>>> sender to, for example > >>>> send a less memory intensive version of say an image, > >>> > >>> instead of a full > >>> > >>>> blown memory hungry > >>>> version. This will allow the information to be communicated with = a > >>>> decreased risk of truncation > >>>> at first try. That makes for a more efficient communication (than > >>>> without this feature). > >>> > >>> This is the most compelling argument for this feature that I > >>> have seen. > >>> > >>> 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-bounces@ietf.org Wed Jun 30 14:49:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05209 for ; Wed, 30 Jun 2004 14:49:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfk98-0005vR-47 for simple-archive@ietf.org; Wed, 30 Jun 2004 14:49:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfk88-0005WB-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 14:48:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfk75-0004lI-00; Wed, 30 Jun 2004 14:47:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfk3C-0004hb-FV; Wed, 30 Jun 2004 14:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfjvf-0003um-81 for simple@megatron.ietf.org; Wed, 30 Jun 2004 14:35: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 OAA04356 for ; Wed, 30 Jun 2004 14:35:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfjve-0000E2-6W for simple@ietf.org; Wed, 30 Jun 2004 14:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfjun-0007eE-00 for simple@ietf.org; Wed, 30 Jun 2004 14:34:38 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BfjuB-0007EZ-00 for simple@ietf.org; Wed, 30 Jun 2004 14:33:59 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Wed, 30 Jun 2004 11:33:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 11:33:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 11:33:23 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 30 Jun 2004 11:33:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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 Boundary header Date: Wed, 30 Jun 2004 11:33:27 -0700 Message-ID: Thread-Topic: [Simple] MSRP Boundary header thread-index: AcRepSfJAdph+7nlQxeQMyB2Pb8lPAAK2VfQ From: "Vijay Kishen Hampapur Parthasarathy" To: "Ben Campbell" , "Paul Kyzivat" X-OriginalArrivalTime: 30 Jun 2004 18:33:31.0951 (UTC) FILETIME=[BEBD6BF0:01C45ED0] Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , seancolson@yahoo.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Can you comment on the initial question on why not allow both methods for message framing. =20 Vijay -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: Wednesday, June 30, 2004 6:20 AM To: Paul Kyzivat Cc: Ted Hardie; seancolson@yahoo.com; Vijay Kishen Hampapur Parthasarathy; simple@ietf.org Subject: Re: [Simple] MSRP Boundary header Paul Kyzivat wrote: >=20 >=20 > Ted Hardie wrote: >=20 >> At 7:48 PM -0700 6/29/04, Sean Olson wrote: >> >>> Why not allow both methods? >>> It seems clear that there are probably two common use cases: >>> >>> 1) Simple, brief messages as in today's IM conversations >>> 2) Larger, more complex, richer messages as forseen in 3G and other=20 >>> environments >> >> >> >> Sorry to ask such a potentially silly question, but aren't the=20 >> messages in case one to be handled by SIP/SIMPLE, rather than MSRP? >=20 >=20 > No. Maybe if you have a one-shot message it should be. But if you are=20 > having a conversation composed of simple brief messages then I believe > the expectation is that you would be using MSRP. >=20 Or at one composed of a series of short, interactive messages. (Which is probably what Paul meant to say. > At least that is my expectation. One subject that has yet to be dealt=20 > with is the relationship (and possibly migration) between page mode=20 > and session mode. The fact that you ask the question you did is an=20 > indication that this isn't a solved problem. >=20 This is true. We have had discussions indicating that we need to say something about when to use each, and how to transition between them. I personally think that sort of thing belong in the SIMPLE architecture draft effort, which we have not been putting much effort into of late. > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 14:57:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06355 for ; Wed, 30 Jun 2004 14:57:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfkHF-00018B-QW for simple-archive@ietf.org; Wed, 30 Jun 2004 14:57:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfkFt-0000d8-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 14:56:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfkDf-0007Fl-00; Wed, 30 Jun 2004 14:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfk3K-0004nT-3h; Wed, 30 Jun 2004 14:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfjyU-00041g-KM for simple@megatron.ietf.org; Wed, 30 Jun 2004 14:38: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 OAA04506 for ; Wed, 30 Jun 2004 14:38:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfjyT-0001ML-FO for simple@ietf.org; Wed, 30 Jun 2004 14:38:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfjxV-0000yk-00 for simple@ietf.org; Wed, 30 Jun 2004 14:37:26 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BfjwV-0000Eb-00 for simple@ietf.org; Wed, 30 Jun 2004 14:36:23 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i5UIZ6Lp017152; Wed, 30 Jun 2004 13:35:06 -0500 Message-ID: <40E307DB.3000105@dynamicsoft.com> Date: Wed, 30 Jun 2004 13:35:07 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Kishen Hampapur Parthasarathy Subject: Re: [Simple] MSRP Boundary header References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Paul Kyzivat , seancolson@yahoo.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Because having two ways to do the same thing adds complexity to both the implementation and the specification. Vijay Kishen Hampapur Parthasarathy wrote: > Can you comment on the initial question on why not allow both methods > for message framing. > > Vijay > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, June 30, 2004 6:20 AM > To: Paul Kyzivat > Cc: Ted Hardie; seancolson@yahoo.com; Vijay Kishen Hampapur > Parthasarathy; simple@ietf.org > Subject: Re: [Simple] MSRP Boundary header > > > > Paul Kyzivat wrote: > > >> >>Ted Hardie wrote: >> >> >>>At 7:48 PM -0700 6/29/04, Sean Olson wrote: >>> >>> >>>>Why not allow both methods? >>>>It seems clear that there are probably two common use cases: >>>> >>>>1) Simple, brief messages as in today's IM conversations >>>>2) Larger, more complex, richer messages as forseen in 3G and other >>>>environments >>> >>> >>> >>>Sorry to ask such a potentially silly question, but aren't the >>>messages in case one to be handled by SIP/SIMPLE, rather than MSRP? >> >> >>No. Maybe if you have a one-shot message it should be. But if you are >>having a conversation composed of simple brief messages then I believe > > >>the expectation is that you would be using MSRP. >> > > > Or at one composed of a series of short, interactive messages. (Which is > probably what Paul meant to say. > > >>At least that is my expectation. One subject that has yet to be dealt >>with is the relationship (and possibly migration) between page mode >>and session mode. The fact that you ask the question you did is an >>indication that this isn't a solved problem. >> > > > This is true. We have had discussions indicating that we need to say > something about when to use each, and how to transition between them. > > I personally think that sort of thing belong in the SIMPLE architecture > draft effort, which we have not been putting much effort into of late. > > >> Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 15:05:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07011 for ; Wed, 30 Jun 2004 15:05:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfkOf-0004Kw-44 for simple-archive@ietf.org; Wed, 30 Jun 2004 15:05:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfkNf-0003wN-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 15:04:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfkMp-0003BZ-00; Wed, 30 Jun 2004 15:03:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfkIz-0006vV-79; Wed, 30 Jun 2004 14:59:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfk6M-0005Ki-5t for simple@megatron.ietf.org; Wed, 30 Jun 2004 14:46: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 OAA05124 for ; Wed, 30 Jun 2004 14:46:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfk6L-0004kF-3k for simple@ietf.org; Wed, 30 Jun 2004 14:46:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfk5W-0004Mm-00 for simple@ietf.org; Wed, 30 Jun 2004 14:45:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Bfk4h-0003y4-00 for simple@ietf.org; Wed, 30 Jun 2004 14:44:51 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UIihJ27199; Wed, 30 Jun 2004 21:44:43 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 21:44:43 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5UIihsL031647; Wed, 30 Jun 2004 21:44:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00zZ0QQN; Wed, 30 Jun 2004 21:44:41 EEST Received: from nokia.com (esnira-pool401599.nokia.com [10.162.15.99]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UIiRH01670; Wed, 30 Jun 2004 21:44:27 +0300 (EET DST) Message-ID: <40E30A07.6090407@nokia.com> Date: Wed, 30 Jun 2004 21:44:23 +0300 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple ele ments References: <1086870176.2885.93.camel@xitami.research.nokia.com> <40E1D831.9090602@dynamicsoft.com> In-Reply-To: <40E1D831.9090602@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: > responses inline. But first, I will say that there was really strong > consensus during the interim to omit this feature in the first version > of the specification. As such, unless others speak out in favor of > adding it, I think that we can declare that the consensus in the interim > > Jari Urpalainen wrote: > > >>> (2) the server keeps a copy of the document before the operation. It=20 >>> then tries the PUT. Once done, it pretends that the client did a GET=20 >>> back to the same URI, and it sees what comes back. If its the same >>> as=20 >>> was in the body of the PUT, the operation was idempotent, and the >>> PUT i= accepted. If not, the server goes back to the document before >>> the=20 >>> operation was done, and rejects the PUT request. This can be >>> summarized= >>> as "try it and see if it works". >>> =20 >> >> >> >> model (2) is almost what i have implemented for the following reason: >> >> first you have a document like >> >> >> >> >> and then a client might try to e.g. add foo/bar[@id=3D"5"] with content >> . First, as we don't find any node with the request, it is >> an appending request and without any error-checking you may end up with >> an end document like >> >> >> >> >> >> >> Clearly this is an error in the client and IMO the server has to detect >> this. The easy way that I chose to check this error-condition is that I >> check that the last XPATH location step will return the correct node. So >> my point is that not only the multi-inserts need this checking.=20 > > > You are right that this problem can happen even in the single-insert > cast. However, there, its much, much easier to check. You merely need > to make sure that the attribute predicate in the r-uri applies to the > element in the body of the request. That can be done before the > insertion operation even takes place, thus avoiding the need for any > kind of roll-back. well, IMO my approach is easier it you consider also the following examples. Also when doing schema checking I'll also need some temporary storage of the resource. > >> >> Jonathan, I have still this question in another thread, where >> idempotency is easily broken during replace (or modify) with single >> nodes too. > > > Different from the above issue? Can you please restate it? > > first you'll have then you want to modify this foo-node with a r-uri .../foo[@a="bar"] and with new content . So we would find a single node and would replace the foo-node with new content and therefore you can't get this new content with the same r-uri anymore. Of course this can be avoided with a request like .../foo[1]. The bad thing here is that the request looks ok (unambiguous) but it is not idempotent and you really need error-checking in the server. This will happen also with attribute updates like put .../foo[@a="bar"]/@a with content "foobar" >> Btw. could someonce explain how DELETE can be idempotent >> (rfc2616) ? > > > Its a mystery to me. The second DELETE will generate a 404, since the > previous one did a good job of deleting the resource. > >>> HTTP PUT operations. So long as you don't need the etag from the=20 >>> previous operation, this would work. Its bandwidth overhead is >>> almost=20 >>> the same as multiple insertions that we've been proposing, and the=20 >>> latency is just about the same thing too. >>> =20 >> >> >> >> I'd rather say that pipelining could work in some cases, but it is NOT a >> solution for doing atomic conditional multi-insertions/deletions which I >> still would like to see in XCAP.=20 > > > Well, again it comes back to what xcap is trying to do. It is not > meant to be a general XML database protocol. I think its a feature of > the design that it can be pushed towards that by adding features like > multiple-inserts, but really its not our goal. > > Also, I'll note that if you want a sequence of insertions AND > deletions to be done atomically, you can't do that with the > multiple-inserts appraoch, since that only works with a single PUT (no > DELETE). Thus, you would need proper transaction semantics that allow > you to lock the document, make a bunch of changes, and cancel/rollback > or commit when done, and that is, I think, well beyond what we want here. > I am not fully following here. In my implementation I will effectively do a locking for the resource before doing any xml-operations, because simultaneous requests (multithreaded implementation) would crash the whole system. So with multi-inserts also the lock is held between all the requests, which will be applied sequentially one by one. After this adding some additional checking is needed to fulfil an unambiguos request, first I'll check that I will still find the same nodes that I inserted and if that is satisfied I'll check that nodes are not related. To me this looks still very simple and is also trivial to implement. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 30 17:33:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21766 for ; Wed, 30 Jun 2004 17:33:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfmhx-0007Wo-SQ for simple-archive@ietf.org; Wed, 30 Jun 2004 17:33:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfmgu-00077y-00 for simple-archive@ietf.org; Wed, 30 Jun 2004 17:32:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfmfp-0006ON-00; Wed, 30 Jun 2004 17:31:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfmVZ-0005ph-UW; Wed, 30 Jun 2004 17:20:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfmHP-0003D4-8Z for simple@megatron.ietf.org; Wed, 30 Jun 2004 17:06: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 RAA19439 for ; Wed, 30 Jun 2004 17:06:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfmHN-0004hZ-MO for simple@ietf.org; Wed, 30 Jun 2004 17:06:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfmC7-0003Aq-00 for simple@ietf.org; Wed, 30 Jun 2004 17:00:42 -0400 Received: from av1-1-sn4.m-sp.skanova.net ([81.228.10.116]) by ietf-mx with esmtp (Exim 4.12) id 1Bfm38-0000ww-00 for simple@ietf.org; Wed, 30 Jun 2004 16:51:22 -0400 Received: by av1-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 236A837EC9; Wed, 30 Jun 2004 22:50:52 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av1-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 1170137E42; Wed, 30 Jun 2004 22:50:52 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 13B1F37E52; Wed, 30 Jun 2004 22:50:51 +0200 (CEST) From: "Gunnar Hellstrom" To: , , Subject: RE: [Simple] Using MSRP for real time text conversation Date: Wed, 30 Jun 2004 22:50:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797CE4@esebe019.ntc.nokia.com> Importance: Normal Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: stf267@etsi.org, adam@dynamicsoft.com, toip@snowshore.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham asks: "can you remind me why we are discussing using MSRP for real time text?" This was the initiating message from Cullen, coming from avt, where we di= scussed details in RFC2793bis. "Dropped off sipping and avt and added simple mailing list... I like this list but I think you have one other thing you want. You want = to make a protocol that actually gets build and deployed. The narrower the market is that is addressed by your solution or as it gets more complex t= o build, the less the odds are of it being build. IM is going to be build. Session mode IM is highly likely to be build. What would you need changed to the current requirements for session mode = IM in SIMPLE for it to meet all of your requirements? I believe there are ex= tra requirements, I=B9m just trying to figure out what they are so perhaps we= can see if they can be addressed in IM. Cullen" So, it was merely picking up a market related thought. The thought of using tcp for text conversation has been up for discussion= on and off through the years. It is allowed but not preferred in H.323. In SIP it ha= s been out of question so far. We know by experience that we have a fully functional RT= P specification that easily flows with its companion media, and presents with satisfactor= y reliability. But Cullen=B4s challenge was too tempting, so we did the feasability stud= y, and today Mary added weight to the discussion, claiming that we have an obligation to go= ahead. I also did an interesting experiment today. I and my deaf son set up a te= xt session with two text/t140 clients. One was set to send immediately, the other we set = to different buffer times. At 300 ms both were quite satisfied with the dialogue quali= ty. At 500 ms, I still thought it was well usable even if a bit gluish, while he definitel= y did not like the non-direct feeling, but could of course converse through it without r= eal problems. That was a rapid validation of the figures in RFC2793 and T.140. They say= that 500 ms is upper limit and 300 ms shoud be default. So, further discussions will need to settle if we need to stay with the p= seudo-real time buffering of 500 ms or if we dare to leave an opening for the good 300 ms= . Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf >Of hisham.khartabil@nokia.com >Sent: Wednesday, June 30, 2004 10:05 AM >To: gunnar.hellstrom@omnitor.se; dean.willis@softarmor.com; >bcampbell@dynamicsoft.com >Cc: stf267@etsi.org; toip@snowshore.com; adam@dynamicsoft.com; >simple@ietf.org >Subject: RE: [Simple] Using MSRP for real time text conversation > > > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf >> Of ext Gunnar Hellstrom >> Sent: 29.June.2004 22:58 >> To: Dean Willis; Ben Campbell >> Cc: STF267; Adam Roach; toip@snowshore.com; simple@ietf.org >> Subject: RE: [Simple] Using MSRP for real time text conversation >> >> >> Thanks for good summaries and questions. >> Comments inline, >> >> >> >Re-adding my comments to this branch of the thread: >> > >> >Dean Willis wrote: >> > >> >> >> >> >> >> Adam Roach wrote: >> >> >> >>> Gunnar: >> >>> >> >>> I'm very confused. Why do you want to use MSRP for T.140 text? You >> >>> don't *need* MSRP to have T.140 conversations. You just carry them >> >>> like any other real-time streams -- isn't that the point >> of RFC 2793? >> >>> >> >> >> >> Darn these cross-list discussions. You and Hisham seem to >> have missed >> >> the first forty messages in this thread, and reacted with >> justifiable >> >> surprise. >> >> >> >> Recap, for those who missed the first season of our serial drama: >> >> >> >> Gunnar does NOT "want" to use MSRP -- he proposed using >> T.140 exactly as >> >> you discussed it above. He also wants real-time text in >> every phone and >> >> messaging device produced, for 100% availability, a goal >> that I find >> >> agreeable. >> >> >> >> However, I don't want to use T.140. Emulating reliability >> by requiring >> >> multiple transmissions of every character without regard for real >> >> network conditions is a horrible violation of the >> principles of RFC2914. >> >> It is not T.140 you are suspicious to, it is to use the RTP >> packetisation text/t140 as >> specified in rfc2793 ( and -bis ) that you have doubts about. >> >> The repetitions are sent together with new characters, and >> therefore do not cause any >> remarkable increase in load. >> >> The unusual characteristics of this rtp packetization makes >> it not as horrible as you seem >> to think. > >If it is not as horrible, then can you remind me why we are discussing u= sing >MSRP for real time text? I am confused now since Dean gave the reason, b= ut you >replied saying that reasoning is not entirely true. > >Thanks, >Hisham > >> >> It is not a true character-by-character transmission. All >> characters typed during a >> buffering interval are transmitted together. The default >> buffering time is 300 ms. If no >> data is available for transmission, no packet is sent. >> >> User spend often more time thinking and reading than they >> spend typing. So, studying max >> values does not give you a good view of the real ( low ) load. >> >> The additional words about actions in case of congestion >> should be effective. RTCP info >> can be the base for increasing buffering time. >> >> >> >> >> So, I raised the question: Could we use a reliable and >> 2914-compliant >> >> protocol like MSRP to meet the needs of real-time text? We are now >> >> discussing this possibility, using MSRP as the baseline. >> >> >> >> Open questions: >> >> >> >> 1) Would the user experience be acceptable? >> With 300 ms between transmissions if there is data, I would >> expect MSRP to behave just as >> well as RTP text/t140, assuming that it gets through NAT and >> firewalls. >> >> We saw that the bandwidth seems to be 3 times higher for >> MSRP. If we compensate by >> increasing buffering time we reach 1 second buffering time, >> and that will be regarded too >> slow and chunky. 500 ms is the limit. >> >> >> >> >> 2) What is the bandwidth required, relative to T.140? >> > >> >If you send one char per message, absurdly huge. If you use >> some of the >> >streaming features of MSRP, this might could be somewhat >> mitigated. But >> >this would be an extremely constrained and mutant usage of >> MSRP as it is >> >currently described. >> With maximum allowable 500 ms for MSRP it will be 4 kbit/s. >> With 300 ms buffering it will >> be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a >> mobile situation. Otherwise >> it is probably OK. We are dealing with calls where it will be >> in many cases favourable to >> use video and audio as well. >> > >> >> >> >> 3) How much change would this imply for MSRP? >> >> >> > >> >I am assuming the 1 char per message approach is not even on >> the table. >> >If you use a stream approach, you will need loads of new >> rules about how >> >to do this, and how to signal you want to do it. >> Look at 500 ms buffering instead. >> Would you dare to recommend it then? >> >> >> > >> >> 4) How will this affect the widepsread availability of >> real-time text? >> >> Cullen has proposed that if this is simple as a check-box >> in the GUI of >> >> every MSRP client, then EVERYBODY has eal-time text capability. >> >> >> > >> >I have no opinion on this. The jury is still out on the wide-spread >> >acceptance of MSRP. >> >> I definitely hope that simple and MSRP gets widespread. The >> current fragmentation in the I >> M world is a severely hampering factor for its message-wise >> use. Impossible to procure for >> official use, impossible to use for public services. I wish >> you all luck with a >> standardised protocol to replace the current situation! >> >> But for its influence on the real time variant, I also want >> to listen to the word from the >> jury... >> > >> >> 5) What are the pros and cons of the various approaches >> with respect to >> >> firewalls and NATs? Clearly TCP has some advantages, and MSRP has >> >> relays, but TURN and STUN give us some existing >> infrastructure for T.140. >> >> There are also true SIP aware NAT-routers and firewalls that >> handle SIP and RTP well. I do >> not know how well they handle MSRP. >> >> >> >> 6) is there a sufficient perception of value in the >> community to justify >> >> adding this sort of function to MSRP, or would yet another >> protocol be >> >> required? >> > >> >Well, adding this to the MSRP base spec would be long and >> painful. I am >> >in principle opposed to adding any significant new >> requirements to MSRP, >> >as it would put at serious risk of never completing it. >> Three small things need to be done: >> a. Optional real time transmission in 500 ms buffers. >> b. MIME declaration of the transmission in a new text/t140p >> format that is just the plain >> UTF-8 coded T.140 transmission. >> c. A request on the receiver to add received text for display >> in one window per >> transmitting party. >> >> >> >> > >> >I also don't think that real-time text is in scope, or in >> charter, for >> >SIMPLE. >> > >> >Now, if we, or someone else, decide(s) that it makes sense to extend >> >MSRP to allow this, I am not strongly opposed, as long as it does not >> >disrupt work on the base spec. (I am not by that statement indicating >> >that I do thing it makes sense.) >> > >> Same here, we have to judge the possible outcome of question >> 4 above, and balance it >> against the influence on already started activities to >> specify text/t140 as the way to do >> text conversation, emergency etc. >> >> Gunnar >> >> >> >> -- >> >> Dean >> >> >> >> _______________________________________________ >> >> 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